Mathias Nyman <mathias.ny...@linux.intel.com> writes: >> We set CMD_RING_STATE_ABORTED state under locking. I'm not checking what >> is for taking lock for register though, I guess it should be enough just >> lock around of read=>write of ->cmd_ring if need lock. > > After your patch it should be enough to have the lock only while > reading and writing the cmd_ring register. > > If we want a locking fix that applies more easily to older stable > releases before your change then the lock needs to cover set > CMD_RING_STATE_ABORT, read cmd_reg, write cmd_reg and busiloop > checking CRR bit. Otherwise the stop cmd ring interrupt handler may > restart the ring just before we start checing CRR. The stop cmd ring > interrupt will set the CMD_RING_STATE_ABORTED to > CMD_RING_STATE_RUNNING so ring will really restart in the interrupt > handler.
Just for record (no chance to make patch I myself for now, sorry), while checking locking slightly, I noticed unrelated missing locking. xhci_cleanup_command_queue() We are calling it without locking, but we need to lock for accessing list. Thanks. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html