)]}'
{
  "commit": "6d06bc83a5ae8777a5f7a81c32dd75b8d9b2fe04",
  "tree": "143117d8f647b6edb57168bdee2ad9a9a3f41cc8",
  "parents": [
    "f8db6475a83649689c087a8f52486fcc53e627e9"
  ],
  "author": {
    "name": "Sergey Senozhatsky",
    "email": "senozhatsky@chromium.org",
    "time": "Thu Jan 29 12:10:30 2026 +0900"
  },
  "committer": {
    "name": "Jakub Kicinski",
    "email": "kuba@kernel.org",
    "time": "Fri Jan 30 18:51:11 2026 -0800"
  },
  "message": "net: usb: r8152: fix resume reset deadlock\n\nrtl8152 can trigger device reset during reset which\npotentially can result in a deadlock:\n\n **** DPM device timeout after 10 seconds; 15 seconds until panic ****\n Call Trace:\n \u003cTASK\u003e\n schedule+0x483/0x1370\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock_common+0x1fd/0x470\n __rtl8152_set_mac_address+0x80/0x1f0\n dev_set_mac_address+0x7f/0x150\n rtl8152_post_reset+0x72/0x150\n usb_reset_device+0x1d0/0x220\n rtl8152_resume+0x99/0xc0\n usb_resume_interface+0x3e/0xc0\n usb_resume_both+0x104/0x150\n usb_resume+0x22/0x110\n\nThe problem is that rtl8152 resume calls reset under\ntp-\u003econtrol mutex while reset basically re-enters rtl8152\nand attempts to acquire the same tp-\u003econtrol lock once\nagain.\n\nReset INACCESSIBLE device outside of tp-\u003econtrol mutex\nscope to avoid recursive mutex_lock() deadlock.\n\nFixes: 4933b066fefb (\"r8152: If inaccessible at resume time, issue a reset\")\nReviewed-by: Douglas Anderson \u003cdianders@chromium.org\u003e\nSigned-off-by: Sergey Senozhatsky \u003csenozhatsky@chromium.org\u003e\nLink: https://patch.msgid.link/20260129031106.3805887-1-senozhatsky@chromium.org\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "fa519258386070e798cbc662f1ea52eebf5394e9",
      "old_mode": 33188,
      "old_path": "drivers/net/usb/r8152.c",
      "new_id": "2f3baa5f6e9c940e385de2fb1430a5ce08d6d4d2",
      "new_mode": 33188,
      "new_path": "drivers/net/usb/r8152.c"
    }
  ]
}