Re: [PATCH v5] cxlflash: Base support for IBM CXL Flash Adapter

[Manoj Kumar <manoj@linux.vnet.ibm.com>]

Brian:

Thanks for the quick review. Comments below.

- Manoj

On 6/8/2015 5:56 PM, Brian King wrote:
>> +retry:
>> +	newval = atomic64_dec_if_positive(&afu->room);
>> +	if (!newval) {
>> +		do {
>> +			room = readq_be(&afu->host_map->cmd_room);
>> +			atomic64_set(&afu->room, room);
>> +			if (room)
>> +				goto write_ioarrin;
>> +		} while (nretry++ < MC_ROOM_RETRY_CNT);
>
> It looks like you removed the udelay here. Was that intentional?

Pulled out going to sleep in the queuecommand path.

>> +
>> +		pr_err("%s: no cmd_room to send 0x%X\n",
>> +		       __func__, cmd->rcb.cdb[0]);
>> +		rc = SCSI_MLQUEUE_HOST_BUSY;
>
> If you actually get here, how do you get out of this state? Since now afu->room is
> zero and anyone that comes through here will go to the else if leg.

This was the optimization to avoid the MMIO for both threads. The other 
thread that raced should do the atomic set of afu->room to a positive value.

>> +		goto out;
>> +	} else if (unlikely(newval < 0)) {
>> +		/* This should be rare. i.e. Only if two threads race and
>> +		 * decrement before the MMIO read is done. In this case
>> +		 * just benefit from the other thread having updated
>> +		 * afu->room.
>> +		 */
>> +		if (nretry++ < MC_ROOM_RETRY_CNT)
>
> I'm guessing you'd want the udelay here as well.

Same reason as the queuecommand issue above.