On Thu, Jun 20, 2019 at 03:48:23PM -0400, Doug Ledford wrote: > It's an msleep() waiting for a hardware command to complete. Waiting > synchronously for a command that has the purpose of stopping the card's > operation does not sound like an incorrect locking or concurrency model > to me. It sounds sane, albeit annoying. If it was the only sleep loop you might have a point, but it isn't, every other patch series lately seems to be adding more sleep loops. This sleep loop is already wrapping another sleep loop under __hns_roce_cmq_send() - which, for some reason, doesn't have an interrupt driven completion path. Nor is there any explanation why we need a sleep loop on top of a sleep loop, or why the command is allowed to fail or why retrying the failed command is even a good idea, or why it can't be properly interrupt driven! I'm frankly sick of it, maybe you should review HNS patches for a while.. Jason
