commit 541cd3ee ("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:
 [<c002c598>] (__bug+0x0/0x2c) from [<c0052a54>] (queue_delayed_work_on+0x74/0xf8)
 [<c00529e0>] (queue_delayed_work_on+0x0/0xf8) from [<c0052b30>] (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: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't forget to unlock a mutex in phy_scan_fixups on a fail path.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix kernel-doc parameter name in phy_device.c.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Freescale on-chip TBI PHYs reports PHY ID as 0x0, but as of

commit 3ee82383
Author: Giulio Benetti <giulio.benetti@micronovasrl.com>
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: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

genphy_setup_forced hasn't actually reset the PHY for a long time,
but a comment to that effect remained in the code, so code continued
to act as if it *had* reset the PHY, and called the necessary fixup
functions to respond to a PHY reset.  With no reset, those functions
are no longer needed, so we remove them.
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds the power management support into the physical
abstraction layer.

Suspend and resume functions respectively turns on/off the bit 11
into the PHY Basic mode control register.
Generic PHY device starts supporting PM.

In order to support the wake-on LAN and avoid to put in power down
the PHY device, the MDIO is aware of what the Ethernet device wants to do.

Voluntary, no CONFIG_PM defines were added into the sources.
Also generic suspend/resume functions are exported to allow
other drivers use them (such as genphy_config_aneg etc.).

Within the phy_driver_register function, we need to remove the
memset. It overrides the device driver owner and it is not good.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the case when the phy_ids is mostly Fs and in some case 0x0
due to broken hardware.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A previous patch, 51e2a384, made
genphy_config_aneg() not restart aneg by calling genphy_restart_aneg() if
the advertisement hadn't changed.

But, genphy_restart_aneg() doesn't just restart aneg, it may also *enable*
aneg or un-isolate the PHY from the MII (those functions are controlled by
the same register).  The code to avoid calling genphy_restart_aneg() didn't
consider this.

So, modify genphy_config_aneg() to also check if the PHY needs to have aneg
enabled or be un-isolated before deciding not to restart aneg.

This caused a problem with certain Davicom PHYs, as that driver isolates
the PHY (why?) before calling genphy_config_aneg() and expects the PHY to
be un-isolated by that function.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
Reported-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PHYID returns 0xffff and not 0xffffffff when not found and in some
case(at91sam9263) 0x0. Maybe this patch could be useful.
Signed-off-by: NGiulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Acked-by: NMarcel Holtmann <marcel@holtmann.org>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver core now has this helper function, so might as well use it
instead of forcing the phy code to roll their own version.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch fixes the following build error caused by
commit ed94493f
(mv643xx_eth: convert to phylib):

<--  snip  -->

...
  Building modules, stage 2.
  MODPOST 1280 modules
ERROR: "genphy_restart_aneg" [drivers/net/mv643xx_eth.ko] undefined!
...
make[2]: *** [__modpost] Error 1

<--  snip  -->
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PHY's aneg is configured and restarted whenever the link is brought up,
e.g. when DHCP is started after the kernel has booted.  This can take the
link down for several seconds while auto-negotiation is redone.

If the advertised features haven't changed, then it shouldn't be necessary
to bring down the link and start auto-negotiation over again.

genphy_config_advert() is enhanced to return 0 when the advertised features
haven't been changed and >0 when they have been.

genphy_config_aneg() then uses this information to not call
genphy_restart_aneg() if there has been no change.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit cac1f3c8 factored out the code for get_phy_id so that it
could be reused in multiple places.  Turns out that some of the
users can be modular, so we need to export this symbol as well.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Fix kernel-doc warning:
Warning(linux-2.6.25-git11//drivers/net/phy/phy_device.c:275): No
description found for parameter 'bus_id'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

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: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

We were already doing what amounts to a get_phy_id from within
get_phy_device, and rather than duplicate this for the TBIPA
probing, we might as well just factor it out and make it available
instead.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

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: NNate Case <ncase@xes-inc.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Lately I've got this nice badness on mdio bus removal:

Device 'e0103120:06' does not have a release() function, it is broken and must be fixed.
------------[ cut here ]------------
Badness at drivers/base/core.c:107
NIP: c015c1a8 LR: c015c1a8 CTR: c0157488
REGS: c34bdcf0 TRAP: 0700   Not tainted  (2.6.23-rc5-g9ebadfbb-dirty)
MSR: 00029032 <EE,ME,IR,DR>  CR: 24088422  XER: 00000000
...
[c34bdda0] [c015c1a8] device_release+0x78/0x80 (unreliable)
[c34bddb0] [c01354cc] kobject_cleanup+0x80/0xbc
[c34bddd0] [c01365f0] kref_put+0x54/0x6c
[c34bdde0] [c013543c] kobject_put+0x24/0x34
[c34bddf0] [c015c384] put_device+0x1c/0x2c
[c34bde00] [c0180e84] mdiobus_unregister+0x2c/0x58
...

Though actually there is nothing broken, it just device
subsystem core expects another "pattern" of resource managment.

This patch implement phy device's release function, thus
we're getting rid of this badness.

Also small hidden bug fixed, hope none other introduced. ;-)
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

It gets quite verbose to see every single PHY driver being registered
by default.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

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: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

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: NHans J. Koch <hjk@linutronix.de>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Writing BMCR_RESET bit will reset MII_BMCR to default values. This is
clearly not what we want.
Signed-off-by: NDomen Puncer <domen.puncer@telargo.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Convert function documentation in drivers/net/phy/ to kernel-doc
and add it to DocBook.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The subsystem rwsem is not used by the driver core at all, so the use of
it in the phy code doesn't make any sense.  They might possibly
want to use a local lock, but I am unsure about that.

Cc: netdev <netdev@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sparse complains about differing types from prototype to
definition, so change the u32 to phy_interface_t:

drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect' redeclared with different type (originally declared at include/linux/phy.h:362) - incompatible argument 5 (different signedness)
drivers/net/phy/phy_device.c:190:19: error: symbol 'phy_attach' redeclared with different type (originally declared at include/linux/phy.h:360) - incompatible argument 4 (different signedness)
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

All kcalloc() calls of the form "kcalloc(1,...)" are converted to the
equivalent kzalloc() calls, and a few kcalloc() calls with the incorrect
ordering of the first two arguments are fixed.
Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Greg KH <greg@kroah.com>
Cc: Mark Fasheh <mark.fasheh@oracle.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Most PHYs connect to an ethernet controller over a GMII or MII
interface.  However, a growing number are connected over
different interfaces, such as RGMII or SGMII.

The ethernet driver will tell the PHY what type of connection it
is by setting it manually, or passing it in through phy_connect
(or phy_attach).

Changes include:
* Updates to documentation
* Updates to PHY Lib consumers
* Changes to PHY Lib to add interface support
* Some minor changes to whitespace in phy.h
* gianfar driver now detects interface and passes appropriate
  value to PHY Lib
Signed-off-by: NAndrew Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

* genphy_update_link is now exported
* Added a fix from ncase@xes-inc.com which changes forcing so it
  only updates the link.  Otherwise, it never tries the lower
  values, since it is always overwriting the speed/duplex values
  with the current ones, rather than the intended ones.
* Fixed a bug where bringing up a PHY with no link caused it to
  timeout, and enter forcing mode.  Once in forcing mode,
  plugging in the link didn't autonegotiate.  Now the AN state
  detects the lack of link, and enters the NO_LINK state.  AN
  only times out if the link is up and AN fails
* Cleaned up the PHY_AN case, reducing one level of indentation
  for the timeout code.
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The recent __must_check stuff flagged some error handling bugs.

phy/fixed.c:
* handle device_bind_driver() failure

phy/phy_device.c:
* handle device_bind_driver() failure
* release rwsem upon failure
Signed-off-by: NJeff Garzik <jeff@garzik.org>

While checking gcc 4.1 -Wextra warnings, I stumbled across the following
two warnings:

drivers/net/phy/phy_device.c:528: warning: comparison of unsigned expression < 0 is always false
drivers/net/phy/phy_device.c:546: warning: comparison of unsigned expression < 0 is always false

Since phy_read() returns an integer and can return negative values, it seems
to me the best way to get proper error handling working again is to make val
an int.  Currently it is an u32, so the < 0 check always fails.
Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This makes it possible for HW PHY-less boards to utilize PAL goodies.  Generic
routines to connect to fixed PHY are provided, as well as ability to specify
software callback that fills up link, speed, etc.  information into PHY
descriptor (the latter feature not tested so far).
Signed-off-by: NVitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Andy,

libphy has no license tag. Something like the attached (untested!) patch
is needed. Hopefully such a change finds its way into 2.6.15.

filename: /lib/modules/2.6.15-rc5-3-ppc64/kernel/drivers/net/phy/libphy.ko
vermagic:       2.6.15-rc5-3-ppc64 SMP gcc-4.1
depends:
srcversion:     ACC921B5E82701BE1E6F603

 drivers/net/phy/phy_device.c |    4 ++++
 1 files changed, 4 insertions(+)
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Unused, and causes the files to be needlessly rebuilt in some cases.