On Thu, May 18, 2017 at 04:47:59PM +0530, Selvin Xavier wrote:
> 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.
Ahh, sorry, my bad.
I misread mdelay and msleep.
Sorry about that.
Attachment:
signature.asc
Description: PGP signature
