)]}'
{
  "commit": "fc04b2ccf0edc49e53d2e1251d122e40285233e6",
  "tree": "266068b74f05eec224fe813e96bd18754d498853",
  "parents": [
    "ffcf9c5700e49c0aee42dcba9a12ba21338e8136"
  ],
  "author": {
    "name": "Mateusz Jończyk",
    "email": "mat.jonczyk@o2.pl",
    "time": "Sat Aug 13 15:10:33 2022 +0200"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@kernel.org",
    "time": "Sun Aug 14 11:24:08 2022 +0200"
  },
  "message": "x86/rtc: Rewrite \u0026 simplify mach_get_cmos_time() by deleting duplicated functionality\n\nThere are functions in drivers/rtc/rtc-mc146818-lib.c that handle\nreading from / writing to the CMOS RTC clock. mach_get_cmos_time() in\narch/x86/kernel/rtc.c did not use them and was mostly a duplicate of\nmc146818_get_time(). Modify mach_get_cmos_time() to use\nmc146818_get_time() and remove the duplicated functionality.\n\nmach_get_cmos_time() used a different algorithm than\nmc146818_get_time(), but these functions are equivalent. The major\ndifferences are:\n\n- mc146818_get_time() is better refined and handles various edge\n  conditions,\n\n- when the UIP (\"Update in progress\") bit of the RTC is set,\n  mach_get_cmos_time() was busy waiting with cpu_relax() while\n  mc146818_get_time() is using mdelay(1) in every loop iteration.\n  (However, there is my commit merged for Linux 5.20 / 6.0 to decrease\n  this period to 100us:\n    commit d2a632a8a117 (\"rtc: mc146818-lib: reduce RTC_UIP polling period\")\n  ),\n\n- mach_get_cmos_time() assumed that the RTC year is \u003e\u003d 2000, which\n  may not be true on some old boxes with a dead battery,\n\n- mach_get_cmos_time() was holding the rtc_lock for a long time\n  and could hang if the RTC is broken or not present.\n\nThe RTC writing counterpart, mach_set_rtc_mmss() is already using\nmc146818_get_time() from drivers/rtc. This was done in\n        commit 3195ef59cb42 (\"x86: Do full rtc synchronization with ntp\")\nIt appears that mach_get_cmos_time() was simply forgotten.\n\nmach_get_cmos_time() is really used only in read_persistent_clock64(),\nwhich is called only in a few places in kernel/time/timekeeping.c .\n\n[ mingo: These changes are not supposed to change behavior, but they are\n         not identity transformations either, as mc146818_get_time() is a\n\t better but different implementation of the same logic - so\n\t regressions are possible in principle. ]\n\nSigned-off-by: Mateusz Jończyk \u003cmat.jonczyk@o2.pl\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@kernel.org\u003e\nAcked-by: Alexandre Belloni \u003calexandre.belloni@bootlin.com\u003e\nLink: https://lore.kernel.org/r/20220813131034.768527-1-mat.jonczyk@o2.pl\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "586f718b8e9511681fd843c4f9e9630249c88844",
      "old_mode": 33188,
      "old_path": "arch/x86/kernel/rtc.c",
      "new_id": "1cadc8a15267360c3dbead3e9c0d40e23909b556",
      "new_mode": 33188,
      "new_path": "arch/x86/kernel/rtc.c"
    }
  ]
}