Commit graph

10 commits

Author SHA1 Message Date
James.Smart@Emulex.Com
964b77e776 [SCSI] lpfc: Update to Emulex hba model names
Update adapter names to match Emulex naming conventions.

Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-10-29 10:10:44 -05:00
James.Smart@Emulex.Com
19a7b4aebf [SCSI] update fc_transport for removal of block/unblock functions
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: James Bottomley <James.Bottomley@SteelEye.com>
2005-10-28 21:20:07 -05:00
Andrew Morton
68ce1eb540 [SCSI] lpfc build fix
gcc-2.95.x doesn't do anonymous unions.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-21 16:25:46 -05:00
Andrew Vasquez
f631b4be76 [SCSI] lpfc: use wwn_to_u64() transport helper
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Acked-by: Smart, James <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-10 11:11:48 -05:00
James.Smart@Emulex.Com
918865230e [SCSI] lpfc driver 8.0.30 : convert to use of int_to_scsilun()
Replace use of lpfc_put_lun with midlayer's int_to_scsilun

Remove driver's local definition of lpfc_put_lun (which converts an
int back to a 64-bit LUN) and replace it's use with the recently added
int_to_scsilun function provided by the midlayer.

Note: Embedding midlayer structure in our structure caused
need for more files to include midlayer headers.

Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-12 12:09:01 -05:00
James.Smart@Emulex.Com
f888ba3ce7 [SCSI] lpfc driver 8.0.30 : fix get_stats panic
Fix panic in lpfc_get_stats()

Symptoms: Panic on sysfs stats access

Cause: In lpfc_get_stats() we are writing to memory that we do not
own.

Fix: Fix our stats structure allocation. Embed phba->link_stats in
struct lpfc_hba and stop treating it like rogue structure.

Note: Embedding midlayer/transport structure in our structure caused
need for more files to include midlayer/transport headers.

Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-12 12:08:48 -05:00
James.Smart@Emulex.Com
c44ce17374 [SCSI] lpfc: Update copyright notices
Update copyright notice text and include year 2005.

Add Copyright notice for Christoph Hellwig to several files: lpfc.h
lpfc_attr.c lpfc_els.c lpfc_hbadisc.c lpfc_init.c lpfc_mbox.c
lpfc_mem.c lpfc_nportdisc.c lpfc_scsi.c lpfc_sli.c

Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-07-02 19:08:29 -05:00
James.Smart@Emulex.Com
5542134f61 [SCSI] lpfc: Remove $Id$ keyword strings.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-07-02 19:06:16 -05:00
James.Smart@Emulex.Com
06325e7459 [SCSI] lpfc: Add LP6000 PCI ID
Fix driver not seeing LP6000.  Fix: add PCI id to the pci_device_id
table and a short description for the HBA in get_hba_model_desc().
Also add a default clause to the switch statement that parses the
various PCI ID's.

Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-07-02 17:18:52 -05:00
dea3101e0a lpfc: add Emulex FC driver version 8.0.28
From: 	James.Smart@Emulex.Com

Modified for kernel import and
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-18 13:50:53 -05:00