)]}'
{
  "commit": "5bb96e9f2434b49a5b8f135f2a384974aa73db51",
  "tree": "d7dd01739b93f709114add365e558550f48817e6",
  "parents": [
    "0ec6d95053885055a50d973b3a3906905a78a8bf"
  ],
  "author": {
    "name": "Eugene Surovegin",
    "email": "ebs@ebshome.net",
    "time": "Wed May 16 11:59:48 2007 -0700"
  },
  "committer": {
    "name": "Jeff Garzik",
    "email": "jeff@garzik.org",
    "time": "Thu May 17 20:43:14 2007 -0400"
  },
  "message": "ibm_emac: improved PHY support\n\nOriginal patch is from Jeff Haran  \u003cjharan@brocade.com\u003e with my minor style\nfixes. His comments follow:\n\nThe first problem was in the function that configures the PHY for\nautonegotiation, genmii_setup_aneg(). The original code does a\nread/modify/write of the autonegotiation advertizement register (reg 4),\nfollowed by a read/modify/write of the control register (reg 0). While\nthe original code follows the proper procedure as per reading the IEEE\nspecs, what I found is that on at least one PHY model (National DP83843)\nthe read of the control register comes back with the soft reset bit set\n(bit 15). Because of the read/modify/write operation, this causes the\nwrite to write a 1 back to the reset bit, which initiates a software\nreset of the PHY. This software reset causes the PHY to return to its\npower up state which advertizes all modes of operation, thus negating\nthe write to the autoneg advertizement register. The modification is to\nspin reading the control register until the soft reset bit is clear\nbefore doing the modify/write.\nThe second problem was in the function that configures the PHY for\nforced operation, genmii_setup_forced(). The original code initiates a\nsoftware reset operation via a write of a 1 to bit 15 of the control\nregister (reg 0), but then proceeds to do a second write to that same\nregister without waiting until that reset bit is cleared by the PHY\nitself (which according to the IEEE specs indicates that the PHY reset\nis complete). This is a violation of how one is supposed to use this\nsoftware reset feature of these PHYs and I believe was the cause of\nmysterious, difficult to reproduce link failures that we\u0027ve observed on\nsome of our systems that use this driver. The fix is to modify the\nfunction so that it spins waiting for the reset bit to clear after doing\nthe soft reset and before doing the subsequent write.\n\nSigned-off-by: Jeff Haran \u003cjharan@brocade.com\u003e\nCC: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nSigned-off-by: Eugene Surovegin \u003cebs@ebshome.net\u003e\nSigned-off-by: Jeff Garzik \u003cjeff@garzik.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "9074f76ee2bf2f088f3e838f55ed5e28f9136a34",
      "old_mode": 33188,
      "old_path": "drivers/net/ibm_emac/ibm_emac_phy.c",
      "new_id": "e57862b34caef73b311b64892e03d0090e63c2db",
      "new_mode": 33188,
      "new_path": "drivers/net/ibm_emac/ibm_emac_phy.c"
    }
  ]
}