Commit bcf0bf90 authored by Francois Romieu's avatar Francois Romieu Committed by Francois Romieu

r8169: sync with vendor's driver

- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
  out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
  Explanation: the in-kernel Linux driver is written to allow MM register
  accesses and avoid the IO tax. The relevant BAR register was found at
  base address 1 for the plain-old PCI 8169. User reported lspci show that
  it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
  Typically:
  01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)
          Subsystem: Unknown device 1631:e015
          Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
          Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
          Latency: 0, cache line size 20
          Interrupt: pin A routed to IRQ 16
          Region 0: I/O ports at b800 [size=256]
          Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
          ^^^^^^^^
  So far I have not received any lspci report for the 0x8136 and
  Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
  include a USE_IO_SPACE #define but the bar address is always hardcoded
  to 1 in the MM case. :o/
- the 8168 has been reported to require an extra alignment for its receive
  buffers. The status of the 8167 and 8136 is not known in this regard.
Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
parent 4ff96fa6
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment