On Thu, May 18, 2017 at 4:23 PM, Leon Romanovsky <leon@xxxxxxxxxx> wrote:
>> -int bnxt_qplib_rcfw_block_for_resp(struct bnxt_qplib_rcfw *rcfw, u16 cookie)
>> +static int __block_for_resp(struct bnxt_qplib_rcfw *rcfw, u16 cookie)
>> {
>> - u32 count = -1;
>> + u32 count = RCFW_BLOCKED_CMD_WAIT_COUNT;
>> u16 cbit;
>>
>> - cookie &= RCFW_MAX_COOKIE_VALUE;
>> cbit = cookie % RCFW_MAX_OUTSTANDING_CMD;
>> if (!test_bit(cbit, rcfw->cmdq_bitmap))
>> goto done;
>> do {
>> + mdelay(1); /* 1m sec */
>
> It doesn't work as you may expect. msleep below 20 ms is not reliable.
> See my queued for this cycle commit
> https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/commit/?h=topic/msleep-to-usleep_range
>
>> bnxt_qplib_service_creq((unsigned long)rcfw);
>> } while (test_bit(cbit, rcfw->cmdq_bitmap) && --count);
>> done:
__block_for_resp is called from functions where it is not expected to
sleep (say from create_ah). That is the reason for
using the mdelay instead of sleep. So we may not be able to use
usleep_range here. Both instances of
mdelay are in the atomic contexts.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
