)]}'
{
  "commit": "2fda873fa5f6ef0c893f4f138b5c54e49c24e0a9",
  "tree": "57dd6c3639ba3d046b7cdf9289a4eb1b50cc271c",
  "parents": [
    "073942589355676980ba401cb88c0eb9f065e468"
  ],
  "author": {
    "name": "hathach",
    "email": "thach@tinyusb.org",
    "time": "Mon Aug 17 01:01:54 2026 +0700"
  },
  "committer": {
    "name": "hathach",
    "email": "thach@tinyusb.org",
    "time": "Tue Aug 18 22:07:49 2026 +0700"
  },
  "message": "dcd(ci_hs): rework bus reset handling and bound the register waits\n\nA bus reset was detected only from the port change that ends it, which is late:\nthe manual asks the DCD to clear the endpoint semaphores, cancel every prime and\nfree the dTDs while the reset is still being driven. Enable the reset interrupt\nand do all of that there, in the manual\u0027s order (IMXRT1060RM 42.5.6.2.1,\np.2394), including the two steps that were missing - confirming the port is\nstill being reset, and freeing the dTDs. A failed check means the cleanup\narrived late and the controller may be in an undefined state, so the manual\u0027s\nremedy is carried out rather than noted: a controller reset, followed by the\nfull re-initialisation it then requires, since the reset detaches the device.\n\nThe port change that ends the reset is left with what the manual gives it, the\nnegotiated speed, which the new BUS_RESET_END event carries. A port change is\nclassified by the interrupt that preceded it: a suspend raises no port change of\nits own, the resume that ends it does.\n\nEvery unbounded register spin is now bounded. They waited on bits the hardware\nclears within a frame, but each could hang an interrupt handler outright on a\ncontroller that had stopped responding. The endpoint flush follows all three\nsteps of IMXRT1060RM 42.5.6.6.5 (p.2413), repeating a flush the controller\nrefuses while a packet is in progress - previously reported as success.\n\nEP0 setup handling is hardened alongside: the payload is copied out of the queue\nhead through the volatile qualifier before ENDPTSETUPSTAT is cleared, since that\nclear releases the setup lockout and a back-to-back setup can overwrite the\nbuffer immediately after, and C orders volatile accesses only against each\nother, so a plain memcpy may legally be sunk past the store.\n\nThere is deliberately no unplug detection. IMXRT1060RM 42.7.31 (p.2470) states a\nzero Current Connect Status means the device \"did not attach successfully or was\nforcibly disconnected by the software writing a zero to the Run bit ... It does\nnot state the device being disconnected or suspended\", so a cable pull raises no\nport change at all; VBUS via OTGSC is the manual\u0027s disconnect indicator and is\nboard dependent.\n\nVerified on mimxrt1064_evk: 30 forced bus resets each re-enumerating at high\nspeed with no descriptor errors, plus repeated full usbtest batteries at 30/30\nacross the series.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b209c75455ac7352711cddc550180ed8584ebe48",
      "old_mode": 33188,
      "old_path": "src/portable/chipidea/ci_hs/ci_hs_type.h",
      "new_id": "5baa148219fae525874678573adc41547158d075",
      "new_mode": 33188,
      "new_path": "src/portable/chipidea/ci_hs/ci_hs_type.h"
    },
    {
      "type": "modify",
      "old_id": "8c08c6bd58b1c59f41b36313371e4c39edd8e43a",
      "old_mode": 33188,
      "old_path": "src/portable/chipidea/ci_hs/dcd_ci_hs.c",
      "new_id": "6ab28e0be128a4dc98cfe070a6496424ca548b1c",
      "new_mode": 33188,
      "new_path": "src/portable/chipidea/ci_hs/dcd_ci_hs.c"
    }
  ]
}