[ANNOUNCE] Emulex lpfcdriver v8.0.7 available

[ANNOUNCE] Emulex lpfcdriver v8.0.7 available

[Jamie Wellnitz]

Christoph,

We've posted the 8.0.7 lpfc driver tarball on SourceForge.  The LUN
handling is gone and your patch to remove some dead code related to
lpfc_build_scsi_cmd() is included along with some other cleanup.

The tarball is here:
http://prdownloads.sourceforge.net/lpfcxxxx/lpfcdriver-2.6-8.0.7.tar.gz?download

The full ChangeLog is on SourceForge:
http://sourceforge.net/forum/forum.php?forum_id=393984

Thanks,
Jamie
Jamie.Wellnitz@emulex.com

Re: [ANNOUNCE] Emulex lpfcdriver v8.0.7 available

['Christoph Hellwig']

looking at your lun/target handling changes a little more:

 - lpfc_find_target can lose it's last two arguments
 - lpfc_findnode_scsiid can be merged into lpfc_find_target,
   killing lots of dead checks.
 - it looks like all the callers of lpfc_find_target in lpfc_hbadisc.c
   realy want to be scsi_add_device calls, which calls lpfc_slave_alloc
   meaning lpfc_find_target could be merged into that one.
 - similarly your statemachine should probably call scsi_remove_device
   when a target disappears.

Re: [ANNOUNCE] Emulex lpfcdriver v8.0.7 available

['Christoph Hellwig']

There's some more issues with timer useag in the driver:

 - never to timer->expires = 0, the proper way to stop a timer
   is del_timer, or del_timer_sync if you need to ensure the handler
   isn't running anymore when your finished (typically only needed
   when you free the containing object afterwards)
 - if you just want to modify the timeout use mod_timer, due to using
   del_timer_sync instead of del_timer your delete/change/add cycles
   actually are safe but not otimal, del_timer_sync is very bad on
   large systems. 
 - you can call del_timer/del_timer_sync/mod_timer on any timer object
   init_timer has been called on, no need to check whether it's actually
   running before
 - for the remaining few cases where you need to check that use timer_pending

As a tule of thumb of the above: never poke into timer->expires for a running
timer.

Also the timer data should usually set just after calling timer_init unless
it may change over the lifetime of the timer object which isn't trivial to
get right.