Re: [PATCH 6/9] firewire: fw-sbp2: don't add scsi_device twice

[Stefan Richter]

Jarod Wilson wrote:
> Stefan Richter wrote:
>> When a reconnect failed but re-login succeeded, __scsi_add_device was
>> called again.
>>
>> Signed-off-by: Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx>
> 
> Was the spurious __scsi_add_device simply failing, or was it causing
> other problems as well? I can't remember if I've hit that or not. In
> either case, not calling it when we know we don't need to makes sense.

SCSI core looks up whether the scsi_target and the scsi_device already
exist.  If so, __scsi_add_device succeeds (there should also be a log
message "scsi scan: device exists on %s\n") and returns the pointer to
the existing scsi_device.

The code in fw-sbp2 before this patch series would then continue
appropriately ... except that it misses to call sbp2_cancel_orbs.  Right
now I am not quite sure which consequences that has; probably no serious
ones right now.  SCSI core would call fw-sbp2's eh_abort_handler
eventually which would reset the fetch agent once more and cancel the
timed out ORBs.  So, besides the needless lookups and temporary
allocations in SCSI core, we avoid the additional stall and timeout
until eh_abort_handler hits.

I shall add this to the changelog.

BTW, since the addition of the blocking and unblocking between bus reset
and reconnect/re-login we also need the unblocking call in the re-login
case but not (necessarily) in the first login case.
-- 
Stefan Richter
-=====-==--- --=- -=-==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/