)]}'
{
  "commit": "bcf0bf90cd9e9242b66e0563b6a8c8db2e4c262c",
  "tree": "07c718f1bf9ca8c3699ba31727195f5cf95ab93e",
  "parents": [
    "4ff96fa67379c31ced69f193c7ffba17051f38e8"
  ],
  "author": {
    "name": "Francois Romieu",
    "email": "romieu@fr.zoreil.com",
    "time": "Wed Jul 26 23:14:13 2006 +0200"
  },
  "committer": {
    "name": "Francois Romieu",
    "email": "romieu@electric-eye.fr.zoreil.com",
    "time": "Wed Jul 26 23:23:15 2006 +0200"
  },
  "message": "r8169: sync with vendor\u0027s driver\n\n- add several PCI ID for the PCI-E adapters ;\n- new identification strings ;\n- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the\n  out-of-tree driver. It makes the comparison less hairy ;\n- various magic ;\n- the PCI region for the device with PCI ID 0x8136 is guessed.\n  Explanation: the in-kernel Linux driver is written to allow MM register\n  accesses and avoid the IO tax. The relevant BAR register was found at\n  base address 1 for the plain-old PCI 8169. User reported lspci show that\n  it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.\n  Typically:\n  01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)\n          Subsystem: Unknown device 1631:e015\n          Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-\n          Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL\u003dfast \u003eTAbort- \u003cTAbort- \u003cMAbort- \u003eSERR- \u003cPERR-\n          Latency: 0, cache line size 20\n          Interrupt: pin A routed to IRQ 16\n          Region 0: I/O ports at b800 [size\u003d256]\n          Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size\u003d4K]\n          ^^^^^^^^\n  So far I have not received any lspci report for the 0x8136 and\n  Realtek\u0027s driver do not help: be it under BSD or Linux, their r1000 driver\n  include a USE_IO_SPACE #define but the bar address is always hardcoded\n  to 1 in the MM case. :o/\n- the 8168 has been reported to require an extra alignment for its receive\n  buffers. The status of the 8167 and 8136 is not known in this regard.\n\nSigned-off-by: Francois Romieu \u003cromieu@fr.zoreil.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ca0f303a6b5dffc8677589af431099fd28836bc9",
      "old_mode": 33188,
      "old_path": "drivers/net/r8169.c",
      "new_id": "d0bfe4c8950d2031ea1764680902be249d8baa3c",
      "new_mode": 33188,
      "new_path": "drivers/net/r8169.c"
    }
  ]
}