1. 21 10月, 2010 1 次提交
  2. 15 10月, 2010 1 次提交
  3. 06 5月, 2010 2 次提交
  4. 23 1月, 2010 1 次提交
  5. 11 1月, 2010 1 次提交
  6. 29 1月, 2008 2 次提交
    • A
      igb: PCI-Express 82575 Gigabit Ethernet driver · 9d5c8243
      Auke Kok 提交于
      We are pleased to announce a new Gigabit Ethernet product and its
      driver to the linux community. This product is the Intel(R) 82575
      Gigabit Ethernet adapter family. Physical adapters will be available
      to the public soon. These adapters come in 2- and 4-port versions
      (copper PHY) currently. Other variants will be available later.
      
      The 82575 chipset supports significantly different features that
      warrant a new driver. The descriptor format is (just like the
      ixgbe driver) different. The device can use multiple MSI-X vectors
      and multiple queues for both send and receive. This allows us to
      optimize some of the driver code specifically as well compared to
      the e1000-supported devices.
      
      This version of the igb driver no lnger uses fake netdevices and
      incorporates napi_struct members for each ring to do the multi-
      queue polling. multi-queue is enabled by default and the driver
      supports NAPI mode only.
      
      All the namespace collisions should be gone in this version too. The
      register macro's have been condensed to improve readability.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d5c8243
    • A
      ixgbe: Fix copper PHY initialization code · 3957d63d
      Auke Kok 提交于
      While cleaning up the internal API focussing on Fiber and CX4 code
      we found that I had broken the copper PHY initialization code. This
      patch restores the PHY-specific code. This is mostly uninteresting
      since no copper PHY boards are yet available. The changes have been
      tested against Fiber only as I do not even have copper PHY versions
      of 82598 macs.
      
      This change actually cleans up the API code a bit more and we
      lose some initialization code. A few PHY link detection helper
      lines of code have been snuck into this patch, as well as a
      read flush where it was suspected that this might cause issues.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3957d63d
  7. 11 10月, 2007 1 次提交
    • A
      ixgbe: driver for Intel(R) 82598 PCI-Express 10GbE adapters (v4) · 9a799d71
      Auke Kok 提交于
      This patch adds support for the Intel 82598 PCI-Express 10GbE
      chipset. Devices will be available on the market soon.
      
      This version of the driver is largely the same as the last release:
      
        * Driver uses a single RX and single TX queue, each using 1 MSI-X
        irq vector.
        * Driver runs in NAPI mode only
        * Driver is largely multiqueue-ready (TM)
      
      Changes since 20070803:
        * removed wrappers for hardware functions
        * incorporated e1000e-style HW api reorganization code
        * sparse/checkpatch cleanups, namespace cleanups
        * driver prints out extra debugging information at load time
          identifying adapter board number, mac, phy types
        * removed ixgbe_api.c, ixgbe_api.h, ixgbe_osdep.h
        * driver update to 1.1.18
        * removed ixgbe.txt which contained no useful info anymore
      
      [ Integrated napi_struct changes from Auke as well... -DaveM ]
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NAyyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a799d71
  8. 28 9月, 2006 1 次提交
  9. 17 8月, 2006 1 次提交
  10. 27 5月, 2006 1 次提交
  11. 24 5月, 2006 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4