How to verify xhci command ring abort behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Mathias, Alan,

I would like to verify the cmd abort sequence.
As you know, it should create a scenario to make the CMD execution
timeout. Then driver will handle xhci_handle_command_timeout.
But it is hard to make a CMD execution timeout, so I find a area of command
execution such as "enable slot" below:

        command->completion = &xhci->addr_dev;
        ret = xhci_queue_slot_control(xhci, command, TRB_ENABLE_SLOT, 0);
        if (ret) {
                spin_unlock_irqrestore(&xhci->lock, flags);
                xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
                kfree(command);
                return 0;
        }
        xhci_ring_cmd_db(xhci);
        spin_unlock_irqrestore(&xhci->lock, flags);

add here ----> xhci_handle_command_timeout((unsigned long) xhci);
        wait_for_completion(command->completion);

You see when driver as producer to create the TRBs at CMD ring, then ring the
door bell, that xhc will fetches the TRBs from the ring, and wait the
completion code that the CMD is executed successfully. I add
xhci_handle_command_timeout after ring doorbell, and expect to see the correct
command abort behavior, is that right? Do you have any idea to create this
test envirnoment?

I want to verify this sequence, that's because there is hw quirk that
CMD_RING_RUNNING bit will keep as 1 after send CS/CA to abort current commmand.
So I would like to use completion code instead of checking this bit to confirm
command abort complete.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux