Commit Graph

54 Commits

Author SHA1 Message Date
Andrew Vasquez 91ca7b01ec [SCSI] Add an 'Issue LIP' device attribute in fc_transport class
Ok, here's a patch to add such a common API for fc transport users.
Relevant LLD changes (lpfc and qla2xxx) also present.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-10-28 19:35:25 -05:00
Andreas Herrmann 1832a5862f [SCSI] change port speed definitions for scsi_transport_fc
obviously FC Port Speeds in scsi_transport_fc.h are defined according
to FC-HBA:

#define FC_PORTSPEED_1GBIT              1
#define FC_PORTSPEED_2GBIT              2
#define FC_PORTSPEED_10GBIT             4
#define FC_PORTSPEED_4GBIT              8

Problem is, whoever invented FC-HBA did not care about FC-FS or
FC-GS-x. Following FC-FS/FC-GS-x defintions of port speeds would look
like:

1 GBit: 0x0001
2 GBit: 0x0002
4 GBit: 0x0004
10GBit: 0x0008

(and new in FC-LS:
8 Gbit: 0x0010
16GBit: 0x0020)

I really appreciate if scsi_transport_fc.h would define port speeds
according to FC-GS-x/FC-FS. Thus mapping of port speed capabilities to
values defined in scsi_transport_fc.h can be avoided in the LLDD.

Attached is a patch to change the definitions.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-16 11:25:50 -04:00
Andrew Vasquez 218fba0004 [SCSI] fc_transport: Generalize WWN to u64 interger conversions.
On some platforms the hard-casting of 8 byte node_name and
port_name arrays to an u64 would cause unaligned-access
warnings.  Generalize the conversions with a transport
helper function which performs consistent shifting of WWN
bytes.

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-09-10 11:10:43 -05:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00