Skip to content

GitLab

Switch branch/tag
  1. 14 Jan, 2006 4 commits
  3. 13 Dec, 2005 2 commits
  5. 07 Dec, 2005 1 commit
  7. 09 Nov, 2005 2 commits
  9. 07 Nov, 2005 1 commit
  11. 28 Oct, 2005 5 commits
    • James.Smart@Emulex.Com's avatar
      [SCSI] update fc_transport for removal of block/unblock functions · 19a7b4ae
      James.Smart@Emulex.Com authored 
      

We recently went back to implement a board reset. When we perform the
reset, we wanted to tear down the internal data structures and rebuild
them. Unfortunately, when it came to the rport structure, things were
odd. If we deleted them, the scsi targets and sdevs would be
torn down. Not a good thing for a temporary reset. We could block the
rports, but we either maintain the internal structures to keep the
rport reference (perhaps even replicating what's in the transport),
or we have to fatten the fc transport with new search routines to find
the rport (and deal with a case of a dangling rport that the driver
forgets).

It dawned on me that we had actually reached this state incorrectly.
When the fc transport first started, we did the block/unblock first, then
added the rport interface. The purpose of block/unblock is to hide the
temporary disappearance of the rport (e.g. being deleted, then readded).
Why are we making the driver do the block/unblock ? We should be making
the transport have only an rport add/delete, and the let the transport
handle the block/unblock.

So... This patch removes the existing fc_remote_port_block/unblock
functions. It moves the block/unblock functionality into the
fc_remote_port_add/delete functions.  Updates for the lpfc driver are
included. Qlogic driver updates are also enclosed, thanks to the
contributions of Andrew Vasquez. [Note: the qla2xxx changes are
relative to the scsi-misc-2.6 tree as of this morning - which does
not include the recent patches sent by Andrew]. The zfcp driver does
not use the block/unblock functions.

One last comment: The resulting behavior feels very clean. The LLDD is
concerned only with add/delete, which corresponds to the physical
disappearance.  However, the fact that the scsi target and sdevs are
not immediately torn down after the LLDD calls delete causes an
interesting scenario... the midlayer can call the xxx_slave_alloc and
xxx_queuecommand functions with a sdev that is at the location the
rport used to be. The driver must validate the device exists when it
first enters these functions. In thinking about it, this has always
been the case for the LLDD and these routines. The existing drivers
already check for existence. However, this highlights that simple
validation via data structure dereferencing needs to be watched.
To deal with this, a new transport function, fc_remote_port_chkready()
was created that LLDDs should call when they first enter these two
routines. It validates the rport state, and returns a scsi result
which could be returned. In addition to solving the above, it also
creates consistent behavior from the LLDD's when the block and deletes
are occuring.

Rejections fixed up and
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      19a7b4ae
    • Andrew Vasquez's avatar
      [SCSI] qla2xxx: Update license. · fa90c54f
      Andrew Vasquez authored 
      
Signed-off-by: default avatarAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      fa90c54f
    • Andrew Vasquez's avatar
      [SCSI] qla2xxx: Add support to dynamically enable/disable ZIO. · 4fdfefe5
      Andrew Vasquez authored 
      

ISP23xx and ISP24xx chips have support for an adaptive
method of posting SCSI command completions for multiple SCSI
commands during a single system interrupt.

SCSI commands are placed on the system response queue
without interrupting the host until 1) a delay timer
expires; or 2) a SCSI command completes with an error.

As long as the host software (qla2xxx) services the response
queue for completions (this polling is done during
queuecommand()) within the 'delay timer' period, the
firmware will not generate system interrupt.
Signed-off-by: default avatarAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      4fdfefe5
    • Andrew Vasquez's avatar
      [SCSI] qla2xxx: Correct issue where fcport is prematurely marked DEAD. · 0eedfcf0
      Andrew Vasquez authored 
      

The non-handled failure cases of the Fabric Login mailbox
command handling logic would incorrectly mark the fcport as
dead and not allow the standard port-down-retry-count logic
to manage the transition.
Signed-off-by: default avatarAndrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      0eedfcf0
    • Al Viro's avatar
      [PATCH] gfp_t: drivers/scsi · c53033f6
      Al Viro authored 
      
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c53033f6
  13. 17 Sep, 2005 1 commit
  15. 10 Sep, 2005 1 commit
  17. 04 Sep, 2005 4 commits
  19. 14 Jul, 2005 9 commits
  21. 20 May, 2005 1 commit
  23. 18 Apr, 2005 3 commits
  25. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored 
      Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
      1da177e4