1. 24 8月, 2014 2 次提交
  2. 23 8月, 2014 2 次提交
  3. 17 8月, 2014 4 次提交
  4. 06 8月, 2014 1 次提交
    • F
      Revert "net: phy: Set the driver when registering an MDIO bus device" · ce7991e8
      Fabio Estevam 提交于
      Commit a71e3c37 ("net: phy: Set the driver when registering an MDIO bus
      device") caused the following regression on the fec driver:
      
      root@imx6qsabresd:~# echo mem > /sys/power/state
      PM: Syncing filesystems ... done.
      Freezing user space processes ... (elapsed 0.003 seconds) done.
      Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
      Unable to handle kernel NULL pointer dereference at virtual address 0000002c
      pgd = bcd14000
      [0000002c] *pgd=4d9e0831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] SMP ARM
      Modules linked in:
      CPU: 0 PID: 617 Comm: sh Not tainted 3.16.0 #17
      task: bc0c4e00 ti: bceb6000 task.ti: bceb6000
      PC is at fec_suspend+0x10/0x70
      LR is at dpm_run_callback.isra.7+0x34/0x6c
      pc : [<803f8a98>]    lr : [<80361f44>]    psr: 600f0013
      sp : bceb7d70  ip : bceb7d88  fp : bceb7d84
      r10: 8091523c  r9 : 00000000  r8 : bd88f478
      r7 : 803f8a88  r6 : 81165988  r5 : 00000000  r4 : 00000000
      r3 : 00000000  r2 : 00000000  r1 : bd88f478  r0 : bd88f478
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 4cd1404a  DAC: 00000015
      Process sh (pid: 617, stack limit = 0xbceb6240)
      Stack: (0xbceb7d70 to 0xbceb8000)
      ....
      
      The problem with the original commit is explained by Russell King:
      
      "It has the effect (as can be seen from the oops) of attaching the MDIO bus
      device (itself is a bus-less device) to the platform driver, which means
      that if the platform driver supports power management, it will be called
      to power manage the MDIO bus device.
      
      Moreover, drivers do not expect to be called for power management
      operations for devices which they haven't probed, and certainly not for
      devices which aren't part of the same bus that the driver is registered
      against."
      
      This reverts commit a71e3c37.
      
      Cc: <stable@vger.kernel.org> #3.16
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce7991e8
  5. 05 8月, 2014 1 次提交
  6. 03 8月, 2014 1 次提交
  7. 31 7月, 2014 6 次提交
  8. 30 7月, 2014 1 次提交
    • F
      net: phy: re-apply PHY fixups during phy_register_device · d92f5dec
      Florian Fainelli 提交于
      Commit 87aa9f9c ("net: phy: consolidate PHY reset in phy_init_hw()")
      moved the call to phy_scan_fixups() in phy_init_hw() after a software
      reset is performed.
      
      By the time phy_init_hw() is called in phy_device_register(), no driver
      has been bound to this PHY yet, so all the checks in phy_init_hw()
      against the PHY driver and the PHY driver's config_init function will
      return 0. We will therefore never call phy_scan_fixups() as we should.
      
      Fix this by calling phy_scan_fixups() and check for its return value to
      restore the intended functionality.
      
      This broke PHY drivers which do register an early PHY fixup callback to
      intercept the PHY probing and do things like changing the 32-bits unique
      PHY identifier when a pseudo-PHY address has been used, as well as
      board-specific PHY fixups that need to be applied during driver probe
      time.
      Reported-by: NHauke Merthens <hauke-m@hauke-m.de>
      Reported-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d92f5dec
  9. 25 7月, 2014 2 次提交
  10. 23 7月, 2014 1 次提交
    • S
      dp83640: Fix receive timestamp race condition · 63502b8d
      Stefan Sørensen 提交于
      When timestamping received packets, rx_timestamp_work may be scheduled
      before the timestamps is received from the hardware resulting in the
      packet beeing delivered without the timestamp.
      
      This is fixed by changing the receive timestamp path:
      
      On receiving a packet that need timestamping, the rxts list is
      traversed.  If a match is found, packet+timestamp are delivered,
      otherwise the packet is added to a rx_queue.
      
      When a timestamp arrives rx_queue is traversed and if a matching
      packet is found, it is delivered with the timestamp. Otherwise the
      timestamp is added to the rxts list for matching with packets arriving
      later.
      
      In case the hardware drops a timestamp, a workqueue regularly checks
      the queue for old packets and delivers them without a timestamp.
      Signed-off-by: NStefan Sørensen <stefan.sorensen@spectralink.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63502b8d
  11. 16 7月, 2014 1 次提交
  12. 12 7月, 2014 1 次提交
  13. 10 7月, 2014 1 次提交
  14. 09 7月, 2014 1 次提交
  15. 08 7月, 2014 1 次提交
  16. 02 7月, 2014 5 次提交
  17. 23 6月, 2014 1 次提交
  18. 22 6月, 2014 3 次提交
  19. 12 6月, 2014 1 次提交
  20. 11 6月, 2014 1 次提交
  21. 06 6月, 2014 2 次提交
  22. 30 5月, 2014 1 次提交