1. 15 2月, 2013 7 次提交
    • C
      gianfar: Remove wrong buffer size conditioning to VLAN h/w offload · 13f228da
      Claudiu Manoil 提交于
      The controller's ref manual states clearly that when the hw Rx vlan
      offload feature is enabled, meaning that the VLEX bit from RCTRL is
      correctly enabled, then the hw performs automatic VLAN tag extraction
      and deletion from the ethernet frames. So there's no point in trying to
      increase the rx buff size when rxvlan is on, as the frame is actually
      smaller.
      And the Tx vlan hw accel feature (VLINS) has nothing to do with rx buff
      size computation.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13f228da
    • C
      gianfar: gfar_process_frame returns void · 61db26c6
      Claudiu Manoil 提交于
      No return code is expected from gfar_process_frame(), hence
      change it to return void.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61db26c6
    • C
      gianfar: GRO_DROP is unlikely · bd9e89f2
      Claudiu Manoil 提交于
      The change is significant since it affects the rx hot path.
      Paul observed and documented the effects at asm level, see
      below:
      
      "It turns out that it does make a difference, since gfar_process_frame
      gets inlined, and so the increment code gets moved out of line (I have
      marked the if statment with * and the increment code within "-----"):
      
        ------------------------- as is currently ------------------
           4d14:       80 61 00 18     lwz     r3,24(r1)
           4d18:       7f c4 f3 78     mr      r4,r30
           4d1c:       48 00 00 01     bl      4d1c <gfar_clean_rx_ring+0x10c>
        *  4d20:       2f 83 00 04     cmpwi   cr7,r3,4
           4d24:       40 9e 00 1c     bne-    cr7,4d40
      <gfar_clean_rx_ring+0x130>
              ----------------------------
           4d28:       81 3c 01 f8     lwz     r9,504(r28)
           4d2c:       81 5c 01 fc     lwz     r10,508(r28)
           4d30:       31 4a 00 01     addic   r10,r10,1
           4d34:       7d 29 01 94     addze   r9,r9
           4d38:       91 3c 01 f8     stw     r9,504(r28)
           4d3c:       91 5c 01 fc     stw     r10,508(r28)
              ----------------------------
           4d40:       a0 1f 00 24     lhz     r0,36(r31)
           4d44:       81 3f 00 00     lwz     r9,0(r31)
           4d48:       7f a4 eb 78     mr      r4,r29
           4d4c:       7f e3 fb 78     mr      r3,r31
      
        -------------------------- unlikely ------------------------
           4d14:       80 61 00 18     lwz     r3,24(r1)
           4d18:       7f c4 f3 78     mr      r4,r30
           4d1c:       48 00 00 01     bl      4d1c <gfar_clean_rx_ring+0x10c>
        *  4d20:       2f 83 00 04     cmpwi   cr7,r3,4
           4d24:       41 9e 03 94     beq-    cr7,50b8
      <gfar_clean_rx_ring+0x4a8>
           4d28:       a0 1f 00 24     lhz     r0,36(r31)
           4d2c:       81 3f 00 00     lwz     r9,0(r31)
           4d30:       7f a4 eb 78     mr      r4,r29
           4d34:       7f e3 fb 78     mr      r3,r31
      [...]
           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)
           50d0:       4b ff fc 58     b       4d28 <gfar_clean_rx_ring+0x118>
      
      So, the increment does actually get moved ~1k away."
      
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd9e89f2
    • C
      gianfar: Cleanup and optimize struct gfar_private · b597d20d
      Claudiu Manoil 提交于
      Group run-time critical fields within the 1st cacheline (32B)
      followed by the tx|rx_queue reference arrays and the interrupt
      group instances (gfargrp), all cacheline aligned.
      
      This has several benefits. Firstly comes the performance benefit
      by having the members required by the driver's hot path re-grouped
      in the structure's first cache lines, whereas the unimportant
      members were pushed towards the end of the struct.
      Another benefit comes from eliminating a 24 byte memory hole that
      was rendering gfar_priv's 2nd cacheline useless. The default gcc
      layout of gfar_private leaves an implicit 24 byte hole after the
      errata (enum) member. This patch fixes it.
      
      The uchar bitfields were pushed towards the end of the struct
      as these are not run-time performance critical (used for init
      time operations). Because there is no other 2 byte member
      around to couple the uchar bitfields memeber with, we will
      have an addititnal 2 byte hole after the bitfields. This is
      unsignificant however, and it doesn't influence gfar_priv's
      size, because the whole structure is padded to be a 32B multiple.
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b597d20d
    • C
      gianfar: Add device ref (dev) in gfar_private · 369ec162
      Claudiu Manoil 提交于
      Use device pointer (dev) to simplify the code and to
      avoid double indirections, especially on the hot path.
      
      Basically, instead of accessing priv to get the ofdev
      reference and then accessing the ofdev structure to
      dereference the needed dev pointer, we will get the
      dev pointer directly from priv.
      
      The dev pointer is required on the hot path, see gfar_new_rxbdp
      or gfar_clean_rx_ring (or xmit), and this patch makes
      it available directly from priv's 1st cacheline.
      
      This change is reflected at asm level too, taking (the hot)
      gfar_new_rxbdp():
      initial version -
          18c0:	7c 7e 1b 78 	mr      r30,r3
      
          18d0:	81 69 04 3c 	lwz     r11,1084(r9)
      
          18d8:	34 6b 00 10 	addic.  r3,r11,16
          18dc:	41 82 00 08 	beq-    18e4
      
      patched version -
          18d0:	80 69 04 38 	lwz     r3,1080(r9)
      
          18d8:	2f 83 00 00 	cmpwi   cr7,r3,0
          18dc:	41 9e 00 08 	beq-    cr7,18e4
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      369ec162
    • C
      gianfar: Remove unused device_node ref in gfar_private · 41a20609
      Claudiu Manoil 提交于
      Remove unused device node pointer.
      Remove duplicated SET_NETDEV_DEV().
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41a20609
    • N
      bgmac: add read of interrupt mask after disabling interrupts · 4160815f
      Nathan Hintz 提交于
      The specs prescribe an immediate read of the interrupt mask after
      disabling interrupts.  This patch updates the driver to match the
      specs.
      Signed-off-by: NNathan Hintz <nlhintz@hotmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4160815f
  2. 14 2月, 2013 5 次提交
  3. 13 2月, 2013 8 次提交
    • 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
    • S
      net: fec_mpc52xx: Read MAC address from device-tree · db98f081
      Stefan Roese 提交于
      Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
      (U-Boot) to write the MAC address into the ethernet controller
      registers. The Linux driver should not rely on such a thing. So
      lets read the MAC address from the DT as it should be done here.
      
      The following priority is now used to read the MAC address:
      
      1) First, try OF node MAC address, if not present or invalid, then:
      
      2) Read from MAC address registers, if invalid, then:
      
      3) Log a warning message, and choose a random MAC address.
      
      This fixes a problem with a MPC5200 board that uses the SPL U-Boot
      version without FEC initialization before Linux booting for
      boot speedup.
      
      Additionally a status line is now be printed upon successful
      driver probing, also displaying this MAC address.
      Signed-off-by: NStefan Roese <sr@denx.de>
      Cc: Anatolij Gustschin <agust@denx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db98f081
    • V
      af32de0e
    • M
      driver: net: ethernet: cpsw: dual emac interface implementation · d9ba8f9e
      Mugunthan V N 提交于
      The CPSW switch can act as Dual EMAC by segregating the switch ports
      using VLAN and port VLAN as per the TRM description in
      14.3.2.10.2 Dual Mac Mode
      
      Following CPSW components will be common for both the interfaces.
      * Interrupt source is common for both eth interfaces
      * Interrupt pacing is common for both interfaces
      * Hardware statistics is common for all the ports
      * CPDMA is common for both eth interface
      * CPTS is common for both the interface and it should not be enabled on
        both the interface as timestamping information doesn't contain port
        information.
      
      Constrains
      * Reserved VID of One port should not be used in other interface which will
        enable switching functionality
      * Same VID must not be used in both the interface which will enable switching
        functionality
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9ba8f9e
    • M
      driver: net: ethernet: cpsw: make cpts as pointer · 9232b16d
      Mugunthan V N 提交于
      As CPTS is common module for both EMAC in Dual EMAC mode so making cpts as
      pointer.
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9232b16d
    • M
      driver: net: ethernet: davinci_cpdma: add support for directed packet and source port detection · f6e135c8
      Mugunthan V N 提交于
      * Introduced parameter to add port number for directed packet in cpdma_chan_submit
      * Source port detection macro with DMA descriptor status
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6e135c8
    • A
      ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6 · 96be80ab
      Alexander Duyck 提交于
      The original fix that was applied for setting gso_type required more change
      than necessary because it was assumed ixgbe does RSC on IPv6 frames and this
      is not correct.  RSC is only supported with IPv4/TCP frames only.  As such we
      can simplify the fix and avoid the unnecessary move of eth_type_trans.
      
      The previous patch "ixgbe: fix gso type" and this patch reduce the entire fix
      to one line that sets gso_type to TCPV4 if the frame is RSC.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      96be80ab
  4. 11 2月, 2013 13 次提交
  5. 09 2月, 2013 6 次提交
  6. 08 2月, 2013 1 次提交
    • H
      tg3: add support for Ethernet core in bcm4785 · 7e6c63f0
      Hauke Mehrtens 提交于
      The BCM4785 or sometimes named BMC4705 is a Broadcom SoC which a
      Gigabit 5750 Ethernet core. The core is connected via PCI with the rest
      of the SoC, but it uses some extension.
      
      This core does not use a firmware or an eeprom.
      
      Some devices only have a switch which supports 100MBit/s, this
      currently does not work with this driver.
      
      This patch was original written by Michael Buesch <m@bues.ch> and is in
      OpenWrt for some years now.
      
      This was tested on a Linksys WRT610N V1 and older versions of this patch
      were tested by other people on different devices.
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e6c63f0