1. 25 11月, 2014 1 次提交
    • G
      net/smsc911x: Add minimal runtime PM support · 3a611e26
      Geert Uytterhoeven 提交于
      Add minimal runtime PM support (enable on probe, disable on remove), to
      ensure proper operation with a parent device that uses runtime PM.
      
      This is needed on systems where the external bus controller module of
      the SoC is contained in a PM domain and/or has a gateable functional
      clock. In such cases, before accessing any device connected to the
      external bus, the PM domain must be powered up, and/or the functional
      clock must be enabled, which is typically handled through runtime PM by
      the bus controller driver.
      
      An example of this is the kzm9g development board, where an smsc9220
      Ethernet controller is connected to the Bus State Controller (BSC) of a
      Renesas sh73a0 SoC.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3a611e26
  2. 14 11月, 2014 3 次提交
    • E
      smsc911x: power-up phydev before doing a software reset. · ccf899a2
      Enric Balletbo i Serra 提交于
      With commit be9dad1f ("net: phy: suspend phydev when going
      to HALTED"), the PHY device will be put in a low-power mode using
      BMCR_PDOWN if the the interface is set down. The smsc911x driver does
      a software_reset opening the device driver (ndo_open). In such case,
      the PHY must be powered-up before access to any register and before
      calling the software_reset function. Otherwise, as the PHY is powered
      down the software reset fails and the interface can not be enabled
      again.
      
      This patch fixes this scenario that is easy to reproduce setting down
      the network interface and setting up again.
      
          $ ifconfig eth0 down
          $ ifconfig eth0 up
          ifconfig: SIOCSIFFLAGS: Input/output error
      Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccf899a2
    • A
      net/smsc911x: Fix delays in the PHY enable/disable routines · 6ff53fd3
      Alexander Kochetkov 提交于
      Increased delay in the smsc911x_phy_disable_energy_detect (from 1ms to 2ms).
      Dropped delays in the smsc911x_phy_enable_energy_detect (100ms and 1ms).
      
      The patch affect SMSC LAN generation 4 chips with integrated PHY (LAN9221).
      
      I saw problems with soft reset due to wrong udelay timings.
      After I fixed udelay, I measured the time needed to bring integrated PHY
      from power-down to operational mode (the time beetween clearing EDPWRDOWN
      bit and soft reset complete event). I got 1ms (measured using ktime_get).
      The value is equal to the current value (1ms) used in the
      smsc911x_phy_disable_energy_detect. It is near the upper bound and in order
      to avoid rare soft reset faults it is doubled (2ms).
      
      I don't know official timing for bringing up integrated PHY as specs doesn't
      clarify this (or may be I didn't found).
      
      It looks safe to drop delays before and after setting EDPWRDOWN bit
      (enable PHY power-down mode). I didn't saw any regressions with the patch.
      
      The patch was reviewed by Steve Glendinning and Microchip Team.
      Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
      Acked-by: NSteve Glendinning <steve.glendinning@shawell.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ff53fd3
    • A
      net/smsc911x: Fix rare soft reset timeout issue due to PHY power-down mode · 242bcd5b
      Alexander Kochetkov 提交于
      The patch affect SMSC LAN generation 4 chips with integrated PHY (LAN9221).
      
      It is possible that PHY could enter power-down mode (ENERGYON clear),
      between ENERGYON bit check in smsc911x_phy_disable_energy_detect and SRST
      bit set in smsc911x_soft_reset. This could happen, for example, if someone
      disconnect ethernet cable between the checks. The PHY in a power-down mode
      would prevent the MAC portion of chip to be software reseted.
      
      Initially found by code review, confirmed later using test case.
      
      This is low probability issue, and in order to reproduce it you have to
      run the script:
      
      while true; do
      	ifconfig eth0 down
      	ifconfig eth0 up || break
      done
      
      While the script is running you have to plug/unplug ethernet cable many
      times (using gpio controlled ethernet switch, for example) until get:
      
      [ 4516.477783] ADDRCONF(NETDEV_UP): eth0: link is not ready
      [ 4516.512207] smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xce006000, IRQ: 336
      [ 4516.524658] ADDRCONF(NETDEV_UP): eth0: link is not ready
      [ 4516.559082] smsc911x smsc911x.0: eth0: SMSC911x/921x identified at 0xce006000, IRQ: 336
      [ 4516.571990] ADDRCONF(NETDEV_UP): eth0: link is not ready
      ifconfig: SIOCSIFFLAGS: Input/output error
      
      The patch was reviewed by Steve Glendinning and Microchip Team.
      Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
      Acked-by: NSteve Glendinning <steve.glendinning@shawell.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      242bcd5b
  3. 02 11月, 2014 1 次提交
    • L
      smc91x: retrieve IRQ and trigger flags in a modern way · d52fdbb7
      Linus Walleij 提交于
      The SMC91x is written to explicitly look up the IRQ resource
      from the platform device and extract the IRQ and flags, however
      the platform_get_irq() does additional things, like call
      of_irq_get() in the device tree case, which will translate
      the IRQ using the irqdomain and defer the probe if the
      IRQ host cannot be found.
      
      As we're not looking up the resource, this will not retrieve
      the IRQ flags, but that is better done using
      irqd_get_trigger_type(), as the trigger is what the driver
      wants to modify. We take care to preserve the semantics that
      will make the trigger type provided from the resource
      override any local specifier.
      
      Tested on the Nomadik NHK15 which has its SMC91x IRQ line
      connected to a STMPE2401 GPIO expander on I2C.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d52fdbb7
  4. 01 11月, 2014 1 次提交
  5. 04 10月, 2014 1 次提交
  6. 13 8月, 2014 1 次提交
  7. 12 8月, 2014 1 次提交
  8. 06 8月, 2014 1 次提交
  9. 04 6月, 2014 1 次提交
  10. 14 5月, 2014 1 次提交
  11. 25 4月, 2014 1 次提交
  12. 23 4月, 2014 1 次提交
  13. 04 4月, 2014 1 次提交
  14. 27 3月, 2014 2 次提交
  15. 25 3月, 2014 3 次提交
  16. 21 3月, 2014 1 次提交
  17. 17 1月, 2014 1 次提交
  18. 14 1月, 2014 1 次提交
  19. 04 1月, 2014 1 次提交
  20. 12 12月, 2013 1 次提交
  21. 07 12月, 2013 1 次提交
    • J
      ethernet: Fix FSF address in file headers · 0ab75ae8
      Jeff Kirsher 提交于
      Several files refer to an old address for the Free Software Foundation
      in the file header comment.  Resolve by replacing the address with
      the URL <http://www.gnu.org/licenses/> so that we do not have to keep
      updating the header comments anytime the address changes.
      
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Dimitris Michailidis <dm@chelsio.com>
      CC: Michael Chan <mchan@broadcom.com>
      CC: Santiago Leon <santil@linux.vnet.ibm.com>
      CC: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Manish Chopra <manish.chopra@qlogic.com>
      CC: Sony Chacko <sony.chacko@qlogic.com>
      CC: Rajesh Borundia <rajesh.borundia@qlogic.com>
      CC: Nicolas Pitre <nico@fluxnic.net>
      CC: Steve Glendinning <steve.glendinning@shawell.net>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ab75ae8
  22. 30 11月, 2013 3 次提交
    • L
      net: smc91: fix crash regression on the versatile · a0c20fb0
      Linus Walleij 提交于
      After commit e9e4ea74
      "net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
      The Versatile SMSC LAN91C111 is crashing like this:
      
      ------------[ cut here ]------------
      kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
      Internal error: Oops - BUG: 0 [#1] ARM
      Modules linked in:
      CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
      task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
      PC is at smc_hardware_send_pkt+0x198/0x22c
      LR is at smc_hardware_send_pkt+0x24/0x22c
      pc : [<c01be324>]    lr : [<c01be1b0>]    psr: 20000013
      sp : c6cd1d08  ip : 00000001  fp : 00000000
      r10: c02adb08  r9 : 00000000  r8 : c6ced802
      r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
      r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: 06cf4000  DAC: 00000015
      Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
      Stack: (0xc6cd1d08 to 0xc6cd2000)
      1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
      1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
      1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
      1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
      1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
      1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
      1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
      1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
      1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
      1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
      1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
      1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
      1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
      1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
      1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
      1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
      1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
      1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
      1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
      1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
      1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
      1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
      1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
      [<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
      [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
      [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c)
      [<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c)
      [<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28)
      [<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8)
      [<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc)
      [<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c)
      Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
      ---[ end trace 81104fe70e8da7fe ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      
      This is because the macro operations in smc91x.h defined
      for Versatile are missing SMC_outsw() as used in this
      commit.
      
      The Versatile needs and uses the same accessors as the other
      platforms in the first if(...) clause, just switch it to using
      that and we have one problem less to worry about.
      
      This includes a hunk of a patch from Will Deacon fixin
      the other 32bit platforms as well: Innokom, Ramses, PXA,
      PCM027.
      
      Checkpatch complains about spacing, but I have opted to
      follow the style of this .h-file.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0c20fb0
    • D
      Revert "net: smc91: fix crash regression on the versatile" · 9d38d28b
      David S. Miller 提交于
      This reverts commit b268daff.
      
      I applied the wrong version of this patch, the proper version
      is coming up next.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d38d28b
    • L
      net: smc91: fix crash regression on the versatile · b268daff
      Linus Walleij 提交于
      After commit e9e4ea74
      "net: smc91x: dont't use SMC_outw for fixing up halfword-aligned data"
      The Versatile SMSC LAN91C111 is crashing like this:
      
      ------------[ cut here ]------------
      kernel BUG at /home/linus/linux/drivers/net/ethernet/smsc/smc91x.c:599!
      Internal error: Oops - BUG: 0 [#1] ARM
      Modules linked in:
      CPU: 0 PID: 43 Comm: udhcpc Not tainted 3.13.0-rc1+ #24
      task: c6ccfaa0 ti: c6cd0000 task.ti: c6cd0000
      PC is at smc_hardware_send_pkt+0x198/0x22c
      LR is at smc_hardware_send_pkt+0x24/0x22c
      pc : [<c01be324>]    lr : [<c01be1b0>]    psr: 20000013
      sp : c6cd1d08  ip : 00000001  fp : 00000000
      r10: c02adb08  r9 : 00000000  r8 : c6ced802
      r7 : c786fba0  r6 : 00000146  r5 : c8800000  r4 : c78d6000
      r3 : 0000000f  r2 : 00000146  r1 : 00000000  r0 : 00000031
      Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: 06cf4000  DAC: 00000015
      Process udhcpc (pid: 43, stack limit = 0xc6cd01c0)
      Stack: (0xc6cd1d08 to 0xc6cd2000)
      1d00:                   00000010 c8800000 c78d6000 c786fba0 c78d6000 c01be868
      1d20: c01be7a4 00004000 00000000 c786fba0 c6c12b80 c0208554 000004d0 c780fc60
      1d40: 00000220 c01fb734 00000000 00000000 00000000 c6c9a440 c6c12b80 c78d6000
      1d60: c786fba0 c6c9a440 00000000 c021d1d8 00000000 00000000 c6c12b80 c78d6000
      1d80: c786fba0 00000001 c6c9a440 c02087f8 c6c9a4a0 00080008 00000000 00000000
      1da0: c78d6000 c786fba0 c78d6000 00000138 00000000 00000000 00000000 00000000
      1dc0: 00000000 c027ba74 00000138 00000138 00000001 00000010 c6cedc00 00000000
      1de0: 00000008 c7404400 c6cd1eec c6cd1f14 c067a73c c065c0b8 00000000 c067a740
      1e00: 01ffffff 002040d0 00000000 00000000 00000000 00000000 00000000 ffffffff
      1e20: 43004400 00110022 c6cdef20 c027ae8c c6ccfaa0 be82d65c 00000014 be82d3cc
      1e40: 00000000 00000000 00000000 c01f2870 00000000 00000000 00000000 c6cd1e88
      1e60: c6ccfaa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      1e80: 00000000 00000000 00000031 c7802310 c7802300 00000138 c7404400 c0771da0
      1ea0: 00000000 c6cd1eec c7800340 00000138 be82d65c 00000014 be82d3cc c6cd1f08
      1ec0: 00000014 00000000 c7404400 c7404400 00000138 c01f4628 c78d6000 00000000
      1ee0: 00000000 be82d3cc 00000138 c6cd1f08 00000014 c6cd1ee4 00000001 00000000
      1f00: 00000000 00000000 00080011 00000002 06000000 ffffffff 0000ffff 00000002
      1f20: 06000000 ffffffff 0000ffff c00928c8 c065c520 c6cd1f58 00000003 c009299c
      1f40: 00000003 c065c520 c7404400 00000000 c7404400 c01f2218 c78106b0 c7441cb0
      1f60: 00000000 00000006 c06799fc 00000000 00000000 00000006 00000000 c01f3ee0
      1f80: 00000000 00000000 be82d678 be82d65c 00000014 00000001 00000122 c00139c8
      1fa0: c6cd0000 c0013840 be82d65c 00000014 00000006 be82d3cc 00000138 00000000
      1fc0: be82d65c 00000014 00000001 00000122 00000000 00000000 00018cb1 00000000
      1fe0: 00003801 be82d3a8 0003a0c7 b6e9af08 60000010 00000006 00000000 00000000
      [<c01be324>] (smc_hardware_send_pkt+0x198/0x22c) from [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8)
      [<c01be868>] (smc_hard_start_xmit+0xc4/0x1e8) from [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc)
      [<c0208554>] (dev_hard_start_xmit+0x460/0x4cc) from [<c021d1d8>] (sch_direct_xmit+0x94/0x18c)
      [<c021d1d8>] (sch_direct_xmit+0x94/0x18c) from [<c02087f8>] (dev_queue_xmit+0x238/0x42c)
      [<c02087f8>] (dev_queue_xmit+0x238/0x42c) from [<c027ba74>] (packet_sendmsg+0xbe8/0xd28)
      [<c027ba74>] (packet_sendmsg+0xbe8/0xd28) from [<c01f2870>] (sock_sendmsg+0x84/0xa8)
      [<c01f2870>] (sock_sendmsg+0x84/0xa8) from [<c01f4628>] (SyS_sendto+0xb8/0xdc)
      [<c01f4628>] (SyS_sendto+0xb8/0xdc) from [<c0013840>] (ret_fast_syscall+0x0/0x2c)
      Code: e3130002 1a000001 e3130001 0affffcd (e7f001f2)
      ---[ end trace 81104fe70e8da7fe ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      
      This is because the macro operations in smc91x.h defined
      for Versatile are missing SMC_outsw() as used in this
      commit.
      
      The Versatile needs and uses the same accessors as the other
      platforms in the first if(...) clause, just switch it to using
      that and we have one problem less to worry about.
      
      Checkpatch complains about spacing, but I have opted to
      follow the style of this .h-file.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Jonathan Cameron <jic23@cam.ac.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b268daff
  23. 09 11月, 2013 1 次提交
  24. 07 11月, 2013 2 次提交
  25. 02 11月, 2013 7 次提交
  26. 22 10月, 2013 1 次提交