1. 03 2月, 2008 2 次提交
  2. 24 1月, 2008 1 次提交
  3. 05 12月, 2007 1 次提交
    • A
      PHY: Add the phy_device_release device method. · 6f4a7f41
      Anton Vorontsov 提交于
      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>
      6f4a7f41
  4. 02 12月, 2007 2 次提交
  5. 06 11月, 2007 2 次提交
  6. 20 10月, 2007 1 次提交
  7. 11 10月, 2007 6 次提交
    • S
      Generic bitbanged MDIO library · e2ec4581
      Scott Wood 提交于
      Previously, bitbanged MDIO was only supported in individual
      hardware-specific drivers.  This code factors out the higher level
      protocol implementation, reducing the hardware-specific portion to
      functions setting direction, data, and clock.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      e2ec4581
    • M
      PHYLIB: fix an interrupt loop potential when halting · 6daf6531
      Maciej W. Rozycki 提交于
      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: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Andy Fleming <afleming@freescale.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      6daf6531
    • M
      PHYLIB: IRQ event workqueue handling fixes · 0ac49527
      Maciej W. Rozycki 提交于
      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: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Andy Fleming <afleming@freescale.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      0ac49527
    • M
      PHYLIB: Spinlock fixes for softirqs · 9ff8c68b
      Maciej W. Rozycki 提交于
      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>
      9ff8c68b
    • V
      PHY fixed driver: rework release path and update phy_id notation · 7c32f470
      Vitaly Bordug 提交于
      device_bind_driver() error code returning has been fixed.  release()
      function has been written, so that to free resources in correct way; the
      release path is now clean.
      
      Before the rework, it used to cause
       Device 'fixed@100:1' does not have a release() function, it is broken
       and must be fixed.
       BUG: at drivers/base/core.c:104 device_release()
      
       Call Trace:
        [<ffffffff802ec380>] kobject_cleanup+0x53/0x7e
        [<ffffffff802ec3ab>] kobject_release+0x0/0x9
        [<ffffffff802ecf3f>] kref_put+0x74/0x81
        [<ffffffff8035493b>] fixed_mdio_register_device+0x230/0x265
        [<ffffffff80564d31>] fixed_init+0x1f/0x35
        [<ffffffff802071a4>] init+0x147/0x2fb
        [<ffffffff80223b6e>] schedule_tail+0x36/0x92
        [<ffffffff8020a678>] child_rip+0xa/0x12
        [<ffffffff80311714>] acpi_ds_init_one_object+0x0/0x83
        [<ffffffff8020705d>] init+0x0/0x2fb
        [<ffffffff8020a66e>] child_rip+0x0/0x12
      
      Also changed the notation of the fixed phy definition on
      mdio bus to the form of <speed>+<duplex> to make it able to be used by
      gianfar and ucc_geth that define phy_id strictly as "%d:%d" and cleaned up
      the whitespace issues.
      Signed-off-by: NVitaly Bordug <vitb@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      7c32f470
    • D
      drivers/net/: all drivers/net/ cleanup with ARRAY_SIZE · ff8ac609
      Denis Cheng 提交于
      Signed-off-by: NDenis Cheng <crquan@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      ff8ac609
  8. 20 9月, 2007 1 次提交
  9. 13 9月, 2007 1 次提交
  10. 25 8月, 2007 1 次提交
  11. 08 8月, 2007 1 次提交
  12. 25 7月, 2007 1 次提交
  13. 19 7月, 2007 2 次提交
  14. 11 7月, 2007 2 次提交
  15. 09 7月, 2007 2 次提交
  16. 29 6月, 2007 1 次提交
    • K
      phy: Fix phy_id for Vitesse 824x PHY · 5f708dd9
      Kumar Gala 提交于
      The phy_id specified for the Vitesse 824x PHY would never match because
      it was expecting bits to be set that would be masked by the phy_id_mask.
      Fix the phy_id so it will match properly, and changed the mdio_bus_match
      to mask both the driver and devices phy_id with the mask so we dont have
      this issue in the future.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      5f708dd9
  17. 10 6月, 2007 1 次提交
  18. 25 5月, 2007 1 次提交
  19. 12 5月, 2007 2 次提交
  20. 10 5月, 2007 3 次提交
  21. 28 4月, 2007 3 次提交
  22. 18 2月, 2007 1 次提交
  23. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      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>
      cd354f1a
  24. 10 2月, 2007 1 次提交
    • R
      phy devices: use same arg types · 1a168934
      Randy Dunlap 提交于
      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>
      1a168934