aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi/libfc/fc_libfc.h
AgeCommit message (Collapse)Author
2012-12-14libfc, libfcoe, fcoe: Convert debug_logging macros to pr_infoRobert Love
Convert libfc, libfcoe and fcoe's debug_logging macros to use pr_info() instead of printk(KERN_INFO, ...). checkpatch.pl now complains about this, so convert libfcoe to preferred method. Signed-off-by: Robert Love <robert.w.love@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
2012-03-20scsi: remove the second argument of k[un]map_atomic()Cong Wang
Signed-off-by: Cong Wang <amwang@redhat.com>
2011-05-24[SCSI] libfc: release DDP context if frame_send() failsYi Zou
In case frame_send() fails, make sure to let the underlying HW release the DDP context that has already been set up before calling frame_send(). Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <jbottomley@parallels.com>
2011-02-12[SCSI] libfc: Extending lport's roles for target if there is a registered ↵Kiran Patil
target. Problem: From initaitor machine, when queried role of target (other end of connection), it is "initiator", hence SCSI-ml doesn't send any LUN Inquiry commands. Fix: If there is a registered target for FC_TYPE_FCP, extend lport's params (capability) to be target as well, By default lport params are INITIATOR only. Having this fix, caused initiator to send SCSI LUN inquiry command to target. Signed-off-by: Kiran Patil <kiran.patil@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] libfc: add hook to notify providers of local port changesJoe Eykholt
When an SCST provider is registered, it needs to know what local ports are available for configuration as targets. Add a notifier chain that is invoked when any local port that is added or deleted. Maintain a global list of local ports and add an interator function that calls a given function for every existing local port. This is used when first loading a provider. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] libfc: add hook for FC-4 provider registrationJoe Eykholt
Allow FC-4 provider modules to hook into libfc, mostly for targets. This should allow any FC-4 module to handle PRLI requests and maintain process-association states. Each provider registers its ops with libfc and then will be called for any incoming PRLI for that FC-4 type on any instance. The provider can decide whether to handle that particular instance using any method it likes, such as ACLs or other configuration information. A count is kept of the number of successful PRLIs from the remote port. Providers are called back with an implicit PRLO when the remote port is about to be deleted or has been reset. fc_lport_recv_req() now sends incoming FC-4 requests to FC-4 providers, and there is a built-in provider always registered for handling incoming ELS requests. The call to provider recv() routines uses rcu_read_lock() so that providers aren't removed during the call. That lock is very cheap and shouldn't affect any performance on ELS requests. Providers can rely on the RCU lock to protect a session lookup as well. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-12-21[SCSI] libfc: add print of exchange id for debugging fc_fcpYi Zou
This is very helpful to match up the corresponding exchange to the actual I/O described by the fsp, particularly when you do a side-by-side comparison of the syslog with your trace. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-07-28[SCSI] libfc: add discovery-private pointer for LLDJoe Eykholt
For VN_port to VN_port mode, FIP will do discovery and needs a way to find its state from the local port or discovery structure. It seems that any other LLD that implements its own discovery would also need something like this. Replace disc->lport with disc->priv, and use container_of to find the lport. We could use disc->priv for that, but container_of is smaller and faster. Signed-off-by: Joe Eykholt <jeykholt@cisco.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-05-16[SCSI] libfc: Move the port_id into lportRobert Love
This patch creates a port_id member in struct fc_lport. This allows libfc to just deal with fc_lport instances instead of calling into the fc_host to get the port_id. This change helps in only using symbols necessary for operation from the libfc structures. libfc still needs to change the fc_host_port_id() if the port_id changes so the presentation layer (scsi_transport_fc) can provide the user with the correct value, but libfc shouldn't rely on the presentation layer for operational values. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-04-11[SCSI] libfc: set both precision and field with when printing FC IDsChris Leech
Most of the prints of fabric IDs were specified as %6x, which will not print any leading 0s. It's nice to see leading 0s for identifiers like this, which are a fixed length. This patch sets the precision modifier as well, making the specifier %6.6x, which forces the printing of leading 0s. Signed-off-by: Chris Leech <christopher.leech@intel.com> Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: Formatting cleanups across libfcRobert Love
This patch makes a variety of cleanup changes to all libfc files. This patch adds kernel-doc headers to all functions lacking them and attempts to better format existing headers. It also add kernel-doc headers to structures. This patch ensures that the current naming conventions for local ports, remote ports and remote port private data is upheld in the following manner. struct instance (i.e. variable name) -------------------------------------------------- fc_lport lport fc_rport rport fc_rport_libfc_priv rpriv fc_rport_priv rdata I also renamed dns_rp and ptp_rp to dns_rdata and ptp_rdata respectively. I used emacs 'indent-region' and 'tabify' on all libfc files to correct spacing alignments. I feel sorry for anyone attempting to review this patch. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: Add routine to copy data from a buffer to a SG listRobert Love
When handling the multi-frame responses of fc pass-thru requests, a code segment similar to fc_fcp_recv_data (routine to receive inbound SCSI data) is used in the response handler. This patch is to add a routine, called fc_copy_buffer_to_sglist(), to handle the common function of copying data from a buffer to a scatter- gather list in order to avoid code duplication. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: Move libfc_init and libfc_exit to fc_libfc.cRobert Love
These routines are for the libfc kernel module and should be in the libfc .c file. Moving the libfc __init routine into fc_libfc.c caused the creation of the fc_setup_fcp() and fc_destroy_fcp() routines so that scsi_pkt_cachep was not exposed outside of fc_fcp.c. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2009-12-04[SCSI] libfc: Add libfc/fc_libfc.[ch] for libfc internal routinesRobert Love
include/scsi/libfc.h is currently loaded with common code shared between libfc's sub-modules as well as shared between libfc and fcoe. Previous patches attempted to move out non-common code. This patch creates two files for common libfc routines that will not be shared with fcoe, fnic or any other LLDs. Signed-off-by: Robert Love <robert.w.love@intel.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>