1. 05 11月, 2016 10 次提交
  2. 01 11月, 2016 13 次提交
  3. 18 10月, 2016 1 次提交
    • J
      ethernet: use core min/max MTU checking · 44770e11
      Jarod Wilson 提交于
      et131x: min_mtu 64, max_mtu 9216
      
      altera_tse: min_mtu 64, max_mtu 1500
      
      amd8111e: min_mtu 60, max_mtu 9000
      
      bnad: min_mtu 46, max_mtu 9000
      
      macb: min_mtu 68, max_mtu 1500 or 10240 depending on hardware capability
      
      xgmac: min_mtu 46, max_mtu 9000
      
      cxgb2: min_mtu 68, max_mtu 9582 (pm3393) or 9600 (vsc7326)
      
      enic: min_mtu 68, max_mtu 9000
      
      gianfar: min_mtu 50, max_mu 9586
      
      hns_enet: min_mtu 68, max_mtu 9578 (v1) or 9706 (v2)
      
      ksz884x: min_mtu 60, max_mtu 1894
      
      myri10ge: min_mtu 68, max_mtu 9000
      
      natsemi: min_mtu 64, max_mtu 2024
      
      nfp: min_mtu 68, max_mtu hardware-specific
      
      forcedeth: min_mtu 64, max_mtu 1500 or 9100, depending on hardware
      
      pch_gbe: min_mtu 46, max_mtu 10300
      
      pasemi_mac: min_mtu 64, max_mtu 9000
      
      qcaspi: min_mtu 46, max_mtu 1500
      - remove qcaspi_netdev_change_mtu as it is now redundant
      
      rocker: min_mtu 68, max_mtu 9000
      
      sxgbe: min_mtu 68, max_mtu 9000
      
      stmmac: min_mtu 46, max_mtu depends on hardware
      
      tehuti: min_mtu 60, max_mtu 16384
      - driver had no max mtu checking, but product docs say 16k jumbo packets
        are supported by the hardware
      
      netcp: min_mtu 68, max_mtu 9486
      - remove netcp_ndo_change_mtu as it is now redundant
      
      via-velocity: min_mtu 64, max_mtu 9000
      
      octeon: min_mtu 46, max_mtu 65370
      
      CC: netdev@vger.kernel.org
      CC: Mark Einon <mark.einon@gmail.com>
      CC: Vince Bridgers <vbridger@opensource.altera.com>
      CC: Rasesh Mody <rasesh.mody@qlogic.com>
      CC: Nicolas Ferre <nicolas.ferre@atmel.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC:  Christian Benvenuti <benve@cisco.com>
      CC: Sujith Sankar <ssujith@cisco.com>
      CC: Govindarajulu Varadarajan <_govind@gmx.com>
      CC: Neel Patel <neepatel@cisco.com>
      CC: Claudiu Manoil <claudiu.manoil@freescale.com>
      CC: Yisen Zhuang <yisen.zhuang@huawei.com>
      CC: Salil Mehta <salil.mehta@huawei.com>
      CC: Hyong-Youb Kim <hykim@myri.com>
      CC: Jakub Kicinski <jakub.kicinski@netronome.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: Byungho An <bh74.an@samsung.com>
      CC: Girish K S <ks.giri@samsung.com>
      CC: Vipul Pandya <vipul.pandya@samsung.com>
      CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      CC: Alexandre Torgue <alexandre.torgue@st.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Wingman Kwok <w-kwok2@ti.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44770e11
  4. 22 9月, 2016 3 次提交
  5. 16 9月, 2016 1 次提交
  6. 09 9月, 2016 2 次提交
  7. 12 7月, 2016 1 次提交
  8. 30 6月, 2016 1 次提交
  9. 18 6月, 2016 1 次提交
  10. 17 6月, 2016 1 次提交
  11. 17 4月, 2016 2 次提交
    • J
      nfp: add async reconfiguration mechanism · 3d780b92
      Jakub Kicinski 提交于
      Some callers of nfp_net_reconfig() are in atomic context so
      we used to busy wait for commands to complete.  In worst case
      scenario that means locking up a core for up to 5 seconds
      when a command times out.  Lets add a timer-based mechanism
      of asynchronously checking whether reconfiguration completed
      successfully for atomic callers to use.  Non-atomic callers
      can now just sleep.
      
      The approach taken is quite simple because (1) synchronous
      reconfigurations always happen under RTNL (or before device
      is registered); (2) we can coalesce pending reconfigs.
      There is no need for request queues, timer which eventually
      takes a look at reconfiguration result to report errors is
      good enough.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d780b92
    • J
      nfp: remove buggy RX buffer length validation · 180012dc
      Jakub Kicinski 提交于
      Meaning of data_len and meta_len RX WB descriptor fields is
      slightly confusing.  Add a comment with a diagram clarifying
      the layout.  Also remove the buffer length validation:
      (a) it's imprecise for static rx-offsets; (b) if firmware
      is buggy enough to DMA past the end of the buffer
      WARN_ON_ONCE() doesn't seem like a strong enough response.
      skb_put() will do the checking for us anyway.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      180012dc
  12. 09 4月, 2016 4 次提交