)]}'
{
  "commit": "d652d5f1eeeb06046009f4fcb9b4542249526916",
  "tree": "18dc20da50fffad8e931bdbd72578bf595854108",
  "parents": [
    "accefff5b547a9a1d959c7e76ad539bf2480e78b"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Dec 17 09:27:57 2020 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Dec 17 09:27:57 2020 -0800"
  },
  "message": "drm/edid: fix objtool warning in drm_cvt_modes()\n\nCommit 991fcb77f490 (\"drm/edid: Fix uninitialized variable in\ndrm_cvt_modes()\") just replaced one warning with another.\n\nThe original warning about a possibly uninitialized variable was due to\nthe compiler not being smart enough to see that the case statement\nactually enumerated all possible cases.  And the initial fix was just to\nadd a \"default\" case that had a single \"unreachable()\", just to tell the\ncompiler that that situation cannot happen.\n\nHowever, that doesn\u0027t actually fix the fundamental reason for the\nproblem: the compiler still doesn\u0027t see that the existing case\nstatements enumerate all possibilities, so the compiler will still\ngenerate code to jump to that unreachable case statement.  It just won\u0027t\ncomplain about an uninitialized variable any more.\n\nSo now the compiler generates code to our inline asm marker that we told\nit would not fall through, and end end result is basically random.  We\nhave created a bridge to nowhere.\n\nAnd then, depending on the random details of just exactly what the\ncompiler ends up doing, \u0027objtool\u0027 might end up complaining about the\nconditional branches (for conditions that cannot happen, and that thus\nwill never be taken - but if the compiler was not smart enough to figure\nthat out, we can\u0027t expect objtool to do so) going off in the weeds.\n\nSo depending on how the compiler has laid out the result, you might see\nsomething like this:\n\n    drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()\n\nand now you have a truly inscrutable warning that makes no sense at all\nunless you start looking at whatever random code the compiler happened\nto generate for our bare \"unreachable()\" statement.\n\nIOW, don\u0027t use \"unreachable()\" unless you have an _active_ operation\nthat generates code that actually makes it obvious that something is not\nreachable (ie an UD instruction or similar).\n\nSolve the \"compiler isn\u0027t smart enough\" problem by just marking one of\nthe cases as \"default\", so that even when the compiler doesn\u0027t otherwise\nsee that we\u0027ve enumerated all cases, the compiler will feel happy and\nsafe about there always being a valid case that initializes the \u0027width\u0027\nvariable.\n\nThis also generates better code, since now the compiler doesn\u0027t generate\ncomparisons for five different possibilities (the four real ones and the\none that can\u0027t happen), but just for the three real ones and \"the rest\"\n(which is that last one).\n\nA smart enough compiler that sees that we cover all the cases won\u0027t care.\n\nCc: Lyude Paul \u003clyude@redhat.com\u003e\nCc: Ilia Mirkin \u003cimirkin@alum.mit.edu\u003e\nCc: Josh Poimboeuf \u003cjpoimboe@redhat.com\u003e\nCc: Peter Zijlstra \u003cpeterz@infradead.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "74f5a3197214cf1a61dc0786e95a56656b0afdc7",
      "old_mode": 33188,
      "old_path": "drivers/gpu/drm/drm_edid.c",
      "new_id": "e95cce8e736dc7090a6091046aae53871e92a27b",
      "new_mode": 33188,
      "new_path": "drivers/gpu/drm/drm_edid.c"
    }
  ]
}