Re: [PATCH 1/1] lpfc: lpfc no longer discovers lun 255

[Brian King <brking@linux.vnet.ibm.com>]

Michael Reed wrote:
> 
> James Bottomley wrote:
>> On Fri, 2009-12-04 at 11:55 -0600, Michael Reed wrote:
>>> Yeah.  I'm working on a patch for qla1280.c also.  Probably others
>>> have been hit.  It would have been nice if the patch author had
>>> fixed all the drivers instead of introducing this change and waiting
>>> for people to discover their last lun is now missing.
>> Actually, lets just revert this:
>>
>> commit 71c309995bff5b5e84253931888b6e8163ee1df0
>> Author: Ed Lin <ed.lin@promise.com>
>> Date:   Fri Oct 9 15:23:27 2009 -0700
>>
>>     [SCSI] fix inconsistent usage of max_lun
>>
>> Which is causing all the problems.  Perhaps we need to update the
>> documentation instead?
>>
>> James
> 
> As much as I would whine about it, I think moving to a consistent
> usage of max_lun is a good thing.  There are only about 140 references
> to max_lun in the cscope output so it wouldn't be that difficult
> for people to go through and fix up their drivers.  And, I suspect
> a good portion will not require any change as they already either
> work correctly with sequential lun scan by design or have misinterpreted
> the meaning of max_lun, and thus will continue to work correctly
> with report lun scan with Mr. Lin's patch applied.

The ibmvfc driver was using 0xffffffff to indicate it essentially had no limit
on the number of LUNs. It appears this can no longer be done with the commit
above since max_lun is an unsigned int.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center