1. 13 8月, 2015 1 次提交
  2. 01 8月, 2015 1 次提交
    • C
      gianfar: Enable device wakeup when appropriate · b0734b6d
      Claudiu Manoil 提交于
      The wol_en flag is 0 by default anyway, and we have the
      following inconsistency: a MAGIC packet wol capable eth
      interface is registered as a wake-up source but unable
      to wake-up the system as wol_en is 0 (wake-on flag set to 'd').
      Calling set_wakeup_enable() at netdev open is just redundant
      because wol_en is 0 by default.
      Let only ethtool call set_wakeup_enable() for now.
      
      The bflock is obviously obsoleted, its utility has been corroded
      over time.  The bitfield flags used today in gianfar are accessed
      only on the init/ config path, with no real possibility of
      concurrency - nothing that would justify smth. like bflock.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0734b6d
  3. 05 2月, 2015 1 次提交
  4. 30 10月, 2014 1 次提交
    • M
      gianfar: Implement PAUSE frame generation support · 45b679c9
      Matei Pavaluca 提交于
      The hardware can automatically generate pause frames when the number
      of free buffers drops under a certain threshold, but in order to do this,
      the address of the last free buffer needs to be written to a specific
      register for each RX queue.
      
      This has to be done in 'gfar_clean_rx_ring' which is called for each
      RX queue. In order not to impact performance, by adding a register write
      for each incoming packet, this operation is done only when the PAUSE frame
      transmission is enabled.
      
      Whenever the link is readjusted, this capability is turned on or off.
      Signed-off-by: NMatei Pavaluca <matei.pavaluca@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45b679c9
  5. 25 4月, 2014 1 次提交
  6. 25 2月, 2014 3 次提交
    • C
      gianfar: Fix Tx int miss, dont write IC on-the-fly · f19015ba
      Claudiu Manoil 提交于
      Programming the interrupt coalescing (IC) registers while
      the controller/DMA is on may incur the loss of one Tx
      confirmation interrupt, under certain conditions.  This is
      a subtle hw race because it does not occur during a burst
      of Tx packets.  It has been observed on p2020 devices that,
      if just one packet is being xmit'ed, the Tx confirmation
      doesn't trigger and BQL evetually blocks the Tx queues,
      followed by Tx timeout and an un-responsive device.
      This issue was not apparent prior to introducing BQL
      support, as a late Tx confirmation was not an issue back then
      and the next burst of Tx frames would have triggered the
      Tx confirmation/ Tx ring cleanup anyway.
      
      Bottom line, the hw specifications state that the IC registers
      should not be programmed while the Rx/Tx blocks (the DMA) are
      enabled. Further more, these registers are currently re-written
      with the same values on the processing path, over and over again.
      To fix this, rewriting the IC registers has been removed from
      the processing path (napi poll).  A complete MAC reset procedure
      has been implemented for the ethtool -c option instead, to
      reliably update these registers while the controller is stopped.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f19015ba
    • C
      gianfar: Fix device reset races (oops) for Tx · 0851133b
      Claudiu Manoil 提交于
      The device reset procedure, stop_gfar()/startup_gfar(), has
      concurrency issues.
      "Kernel access of bad area" oopses show up during Tx timeout
      device reset or other reset cases (like changing MTU) that
      happen while the interface still has traffic. The oopses
      happen in start_xmit and clean_tx_ring when accessing tx_queue->
      tx_skbuff which is NULL. The race comes from de-allocating the
      tx_skbuff while transmission and napi processing are still
      active. Though the Tx queues get temoprarily stopped when Tx
      timeout occurs, they get re-enabled as a result of Tx congestion
      handling inside the napi context (see clean_tx_ring()). Not
      disabling the napi during reset is also a bug, because
      clean_tx_ring() will try to access tx_skbuff while it is being
      de-alloc'ed and re-alloc'ed.
      
      To fix this, stop_gfar() needs to disable napi processing
      after stopping the Tx queues. However, in order to prevent
      clean_tx_ring() to re-enable the Tx queue before the napi
      gets disabled, the device state DOWN has been introduced.
      It prevents the Tx congestion management from re-enabling the
      de-congested Tx queue while the device is brought down.
      An additional locking state, RESETTING, has been introduced
      to prevent simultaneous resets or to prevent configuring the
      device while it is resetting.
      The bogus 'rxlock's (for each Rx queue) have been removed since
      their purpose is not justified, as they don't prevent nor are
      suited to prevent device reset/reconfig races (such as this one).
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0851133b
    • C
      gianfar: Fix on-the-fly vlan and mtu updates · 88302648
      Claudiu Manoil 提交于
      The RCTRL and TCTRL registers should not be changed
      on-the-fly, while the controller is running, otherwise
      unexpected behaviour occurs.  But that's exactly what
      gfar_vlan_mode() does, updating the VLAN acceleration
      bits inside RCTRL/TCTRL.  The attempt to lock these
      operations doesn't help, but only adds to the confusion.
      There's also a dependency for Rx FCB insertion (activating
      /de-activating the TOE offload block on Rx) which might
      change the required rx buffer size.  This makes matters
      worse as gfar_vlan_mode() ends up calling gfar_change_mtu(),
      though the MTU size remains the same.  Note that there are
      other situations that may affect the required rx buffer size,
      like changing RXCSUM or rx hw timestamping, but errorneously
      the rx buffer size is not recomputed/ updated in the process.
      
      To fix this, do the vlan updates properly inside the MAC
      reset and reconfiguration procedure, which takes care of
      the rx buffer size dependecy and the rx TOE block (PRSDEP)
      activation/deactivation as well (in the correct order).
      As a consequence, MTU/ rx buff size updates are done now
      by the same MAC reset and reconfig procedure, so that out
      of context updates to MAXFRM, MRBLR, and MACCFG inside
      change_mtu() are no longer needed.  The rx buffer size
      dependecy to Rx FCB is now handled for the other cases too
      (RXCSUM and rx hw timestamping).
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88302648
  7. 19 2月, 2014 2 次提交
    • C
      gianfar: Remove clean_rx_ring race from gfar_ethtool · 7cca336a
      Claudiu Manoil 提交于
      gfar_clean_rx_ring() was designed to be called from napi
      (rx softirq) context to do the Rx processing. Calling it
      from a process context like this is a bug as it will
      clearly race with the napi Rx processing.
      
      There's also no point in initializing num_txbdfree since
      startup_gfar() already does that, when bringing the device
      up again (after reset). Changing num_txbdfree "on-the-fly"
      like this is also subject to race conditions.  num_txbdfree
      is handled by the Tx processing path and the device reset
      procedure.  Also, don't assume that num_rx_queues is always
      equal to num_tx_queues.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cca336a
    • C
      gianfar: Add missing graceful reset steps and fixes · c10650b6
      Claudiu Manoil 提交于
      gfar_halt() and gfar_start() are responsible for stopping
      and starting the DMA and the Rx/Tx hw rings. They implement
      the support for the "graceful Rx/Tx stop/start" hw procedure,
      and also disable/enable eTSEC's hw interrupts in the process.
      
      The GRS/GTS procedure requires however to have the RQUEUE/TQUEUE
      registers cleared first and to wait for a period of time for the
      current frame to pass through the interface (around ~10ms for a
      jumbo frame). Only then may the GTS and GRS bits from DMACTRL be
      set to shut down the DMA, and finally the Tx_EN and Rx_EN bits in
      MACCFG1 may be cleared to disable the Tx/Rx blocks.
      
      The same register programming order applies to start the Rx/Tx:
      enabling the RQUEUE/TQUEUE *before* clearing the GRS/GTS bits.
      
      This is a HW recommendation in order to avoid a possible
      controller "lock up" during graceful reset.
      
      Cleanup the gfar_halt()/start() prototypes, to take priv instead
      of ndev as their purpose is to operate on HW. Enabling the
      RQUEUE/TQUEUE in the hw_init() is not needed anymore since
      that's the job of gfar_start().
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c10650b6
  8. 17 1月, 2014 1 次提交
  9. 16 1月, 2014 1 次提交
    • C
      gianfar: Fix portabilty issues for ethtool and ptp · 42851e88
      Claudiu Manoil 提交于
      Fixes unhandled register write in gianfar_ethtool.c.
      Fixes following endianess related functional issues,
      reported by sparse as well, i.e.:
      
      gianfar_ethtool.c:1058:33: warning:
          incorrect type in argument 1 (different base types)
          expected unsigned int [unsigned] [usertype] value
          got restricted __be32 [usertype] ip4src
      
      gianfar_ethtool.c:1164:33: warning:
          restricted __be16 degrades to integer
      
      gianfar_ethtool.c:1669:32: warning:
          invalid assignment: ^=
          left side has type restricted __be16
          right side has type int
      
      Solves all the sparse warnings for mixig normal pointers
      with __iomem pointers for gianfar_ptp.c, i.e.:
      gianfar_ptp.c:163:32: warning:
          incorrect type in argument 1 (different address spaces)
          expected unsigned int [noderef] <asn:2>*addr
          got unsigned int *<noident>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42851e88
  10. 14 8月, 2013 1 次提交
    • C
      gianfar: Add flow control support · 23402bdd
      Claudiu Manoil 提交于
      eTSEC has Rx and Tx flow control capabilities that may be enabled
      through MACCFG1[Rx_Flow, Tx_Flow] bits.  These bits must not be set
      however when eTSEC is operated in Half-Duplex mode.  Unfortunately,
      the driver currently sets these bits unconditionally.
      This patch adds the proper handling of the PAUSE frame capability
      register bits by implementing the ethtool -A interface.  When pause
      autoneg is enabled, the controller uses the phy's capability to
      negotiate PAUSE frame settings with the link partner and reconfigures
      its Rx_Flow and Tx_Flow settings to match the capabilities of the
      link partner.  If pause autoneg is off, the PAUSE frame generation
      may be forced manually (ethtool -A).  Flow control is disabled by
      default now.
      This implementation is inspired by the tg3 driver.
      Signed-off-by: NLutz Jaenicke <ljaenicke@innominate.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23402bdd
  11. 20 4月, 2013 1 次提交
  12. 15 4月, 2013 1 次提交
  13. 22 3月, 2013 1 次提交
  14. 21 3月, 2013 1 次提交
  15. 13 2月, 2013 2 次提交
    • P
      gianfar: convert u64 status counters to atomic64_t · 212079df
      Paul Gortmaker 提交于
      While looking at some asm dump for an unrelated change, Eric
      noticed in the following stats count increment code:
      
          50b8:       81 3c 01 f8     lwz     r9,504(r28)
          50bc:       81 5c 01 fc     lwz     r10,508(r28)
          50c0:       31 4a 00 01     addic   r10,r10,1
          50c4:       7d 29 01 94     addze   r9,r9
          50c8:       91 3c 01 f8     stw     r9,504(r28)
          50cc:       91 5c 01 fc     stw     r10,508(r28)
      
      that a 64 bit counter was used on ppc-32 without sync
      and hence the "ethtool -S" output was racy.
      
      Here we convert all the values to use atomic64_t so that
      the output will always be consistent.
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      212079df
    • P
      gianfar: remove largely unused gfar_stats struct · 68719786
      Paul Gortmaker 提交于
      The gfar_stats struct is only used in copying out data
      via ethtool.  It is declared as the extra stats, followed
      by the rmon stats.  However, the rmon stats are never
      actually ever used in the driver; instead the rmon data
      is a u32 register read that is cast directly into the
      ethtool buf.
      
      It seems the only reason rmon is in the struct at all is
      to give the offset(s) at which it should be exported into
      the ethtool buffer.  But note gfar_stats doesn't contain
      a gfar_extra_stats as a substruct -- instead it contains
      a u64 array of equal element count.  This implicitly means
      we have two independent declarations of what gfar_extra_stats
      really is.  Rather than have this duality, we already have
      defines which give us the offset directly, and hence do not
      need the struct at all.
      
      Further, since we know the extra_stats is unconditionally
      always present, we can write it out to the ethtool buf
      1st, and then optionally write out the rmon data.  There
      is no need for two independent loops, both of which are
      simply copying out the extra_stats to buf offset zero.
      
      This also helps pave the way towards allowing the extra
      stats fields to be converted to atomic64_t values, without
      having their types directly influencing the ethtool stats
      export code (gfar_fill_stats) that expects to deal with u64.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      68719786
  16. 05 2月, 2013 1 次提交
  17. 07 1月, 2013 1 次提交
  18. 22 9月, 2012 1 次提交
  19. 06 6月, 2012 1 次提交
  20. 06 4月, 2012 1 次提交
  21. 04 4月, 2012 1 次提交
  22. 16 3月, 2012 1 次提交
  23. 31 1月, 2012 1 次提交
  24. 05 1月, 2012 1 次提交
  25. 22 11月, 2011 1 次提交
  26. 17 11月, 2011 1 次提交
  27. 17 9月, 2011 2 次提交
  28. 12 8月, 2011 1 次提交
    • J
      freescale: Move the Freescale drivers · ec21e2ec
      Jeff Kirsher 提交于
      Move the Freescale drivers into drivers/net/ethernet/freescale/ and
      make the necessary Kconfig and Makefile changes.
      
      CC: Sandeep Gopalpet <sandeep.kumar@freescale.com>
      CC: Andy Fleming <afleming@freescale.com>
      CC: Shlomi Gridish <gridish@freescale.com>
      CC: Li Yang <leoli@freescale.com>
      CC: Pantelis Antoniou <pantelis.antoniou@gmail.com>
      CC: Vitaly Bordug <vbordug@ru.mvista.com>
      CC: Dan Malek <dmalek@jlc.net>
      CC: Sylvain Munaut <tnt@246tNt.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ec21e2ec
  29. 22 7月, 2011 1 次提交
  30. 07 7月, 2011 1 次提交
  31. 21 6月, 2011 1 次提交
    • S
      gianfar v5: implement nfc · 4aa3a715
      Sebastian Poehn 提交于
      This patch adds all missing functionalities for nfc except GRXFH. There is so much code because hardware has not a TCAM.
      Further hardware rule space is very limited. So I had to extensively use
      optimization features. Both reasons lead to the necessity to hold all
      online flows in a linked-list.
      
      Change-log:
      # Some suggestions by Joe Perches applied (thanks!)
      # Shorted some logs
      # Use memcmp() for comparing
      Signed-off-by: NSebastian Poehn <sebastian.poehn@belden.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4aa3a715
  32. 17 6月, 2011 1 次提交
  33. 09 6月, 2011 1 次提交
  34. 16 4月, 2011 1 次提交
  35. 12 4月, 2011 1 次提交