- 22 6月, 2009 1 次提交
-
-
由 Robert Love 提交于
This patch adds the /sys/module/libfc/parameters/debug_logging file to sysfs as a module parameter. It accepts an integer bitmask for logging. Currently it supports: bit LSB 0 = general libfc debugging 1 = lport debugging 2 = disc debugging 3 = rport debugging 4 = fcp debugging 5 = EM debugging 6 = exch/seq debugging 7 = scsi logging (mostly error handling) the other bits are not used at this time. The patch converts all of the libfc source files to use these new macros and removes the old FC_DBG macro. Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 09 6月, 2009 1 次提交
-
-
由 Steve Ma 提交于
When a sequence is received in response to an exchange we issued previously, we should check to see if the exchange has completed. If yes, the sequence should be discarded. Since the exchange might be still in the completion process, it should be untouched. Signed-off-by: NSteve Ma <steve.ma@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 14 3月, 2009 1 次提交
-
-
由 Yi Zou 提交于
When LLD supports direct data placement (ddp) for large receive of an scsi i/o coming into fc_fcp, we call into libfc_function_template's ddp_setup() to prepare for a ddp of large receive for this read I/O. When I/O is complete, we call the corresponding ddp_done() to get the length of data ddped as well as to let LLD do clean up. fc_fcp_ddp_setup()/fc_fcp_ddp_done() are added to setup and complete a ddped read I/O described by the given fc_fcp_pkt. They would call into corresponding ddp_setup/ddp_done implemented by the fcoe layer. Eventually, fcoe layer calls into LLD's ddp_setup/ddp_done provided through net_device Signed-off-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 13 3月, 2009 1 次提交
-
-
由 Julia Lawall 提交于
!ep->esb_stat is either 1 or 0, and the rightmost bit of ESB_ST_COMPLETE is always 0, making the result of !ep->esb_stat & ESB_ST_COMPLETE always 0. Thus parentheses around the argument to ! seem needed. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression E; constant C; @@ ( !E & !C | - !E & C + !(E & C) ) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 10 3月, 2009 2 次提交
-
-
由 Yi Zou 提交于
We shouldn't be altering inbound frames. Signed-off-by: NYi Zou <yi.zou@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Robert Love 提交于
1) There were a few functions with a strange layout, i.e. all arguments on the second line, when not necessary. Where ever possible I moved the return value to the same line as the function name. However, when the line was too long to have a single argument on the same line I moved the return value to above line. For example: <short return> <function name>(<arg 1>, <arg2>) and <very long return value> <function name>(<arg1>, <arg2>) 2) Removed one extra whitespace line 3) Fixed two typos Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 07 3月, 2009 4 次提交
-
-
由 Chris Leech 提交于
This allows any rport ELS to retry on LS_RJT. The rport error handling would only retry on resource allocation failures and exchange timeouts. I have a target that will occasionally reject PLOGI when we do a quick LOGO/PLOGI. When a critical ELS was rejected, libfc would fail silently leaving the rport in a dead state. The retry count and delay are managed by fc_rport_error_retry. If the retry count is exceeded fc_rport_error will be called. When retrying is not the correct course of action, fc_rport_error can be called directly. Signed-off-by: NChris Leech <christopher.leech@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Vasu Dev 提交于
The fc_seq_start_next grabs ep->ex_lock but this lock was already held here, so instead called fc_seq_start_next_locked to avoid soft lockup. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Vasu Dev 提交于
Cleanup exchange held due to RRQ when RRQ exch times out, in this case the ABTS is already done causing RRQ req therefore proceeding with cleanup in fc_exch_rrq_resp should be okay to restore exch resource. Signed-off-by: NVasu Dev <vasu.dev@intel.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
由 Abhijeet Joglekar 提交于
fc_exch_mgr structure is private to fc_exch.c. To export exch_mgr_reset to transport, transport needs access to the exch manager. Change exch_mgr_reset to use lport param which is the shared structure between libFC and transport. Alternatively, fc_exch_mgr definition can be moved to libfc.h so that lport can be accessed from mp*. Signed-off-by: NAbhijeet Joglekar <abjoglek@cisco.com> Signed-off-by: NRobert Love <robert.w.love@intel.com> Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-
- 30 12月, 2008 1 次提交
-
-
由 Robert Love 提交于
libFC is composed of 4 blocks supported by an exchange manager and a framing library. The upper 4 layers are fc_lport, fc_disc, fc_rport and fc_fcp. A LLD that uses libfc could choose to either use libfc's block, or using the transport template defined in libfc.h, override one or more blocks with its own implementation. The EM (Exchange Manager) manages exhcanges/sequences for all commands- ELS, CT and FCP. The framing library frames ELS and CT commands. The fc_lport block manages the library's representation of the host's FC enabled ports. The fc_disc block manages discovery of targets as well as handling changes that occur in the FC fabric (via. RSCN events). The fc_rport block manages the library's representation of other entities in the FC fabric. Currently the library uses this block for targets, its peer when in point-to-point mode and the directory server, but can be extended for other entities if needed. The fc_fcp block interacts with the scsi-ml and handles all I/O. Signed-off-by: NRobert Love <robert.w.love@intel.com> [jejb: added include of delay.h to fix ppc64 compile prob spotted by sfr] Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
-