- 08 Nov, 2016 40 commits
-
-
Hannes Reinecke authored
The ->seq_exch_abort callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
Hannes Reinecke <hare@suse.com> Acked-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
The ->seq_send callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
Function is empty now and can be removed. Signed-off-by:
Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by:
-
Hannes Reinecke authored
The ->rport_flush_queue callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_recv_req callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_logoff callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_login callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_create callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
Required for the next patch. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_lookup callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->rport_destroy callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->exch_seq_send callback only ever had one implementation, so we can call the function directly and drop the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->lport_recv callback only ever had one implementation, so call the function directly and remove the callback. Signed-off-by:
-
Hannes Reinecke authored
The ->lport_reset callback only ever had one implementation, which already is exported. So remove it and use the function directly. Signed-off-by:
-
Hannes Reinecke authored
The 'seq_els_rsp_send' callback only ever had one implementation, so we might as well drop it and use the function directly. Signed-off-by:
-
Michael Cyr authored
Signed-off-by:
Michael Cyr <mikecyr@us.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Tested-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Signed-off-by:
-
Michael Cyr authored
Signed-off-by:
-
Michael Cyr authored
Signed-off-by:
-
Michael Cyr authored
This patch adds code to disconnect from the client, which will make sure any outstanding commands have been completed, before continuing on with the remove operation. Signed-off-by:
-
Michael Cyr authored
This patch changes the way the IBM vSCSI server driver manages its Command/Response Queue (CRQ). We used to register the CRQ with phyp at probe time. Now we wait until tpg_enable_store. Similarly, when tpg_enable_store is called to "disable" (i.e. the stored value is 0), we unregister the queue with phyp. One consquence to this is that we have no need for the PART_UP_WAIT_ENAB state, since we can't get an Init Message from the client in our CRQ if we're waiting to be enabled, since we haven't registered the queue yet. Signed-off-by:
-
Michael Cyr authored
This patch reorders functions in a manner necessary for a follow-on patch. It also makes some minor styling changes (mostly removing extra spaces) and fixes some typos. There are no code changes in this patch, with one exception: due to the reordering of the functions, I needed to explicitly declare a function at the top of the file. However, this will be removed in the next patch, since the code requiring the predeclaration will be removed. Signed-off-by:
-
Arnd Bergmann authored
The driver was changed to call ioport_map, which breaks platforms that cannot provide this function: drivers/scsi/g_NCR5380.o: In function `generic_NCR5380_init_one.constprop.0': g_NCR5380.c:(.text.generic_NCR5380_init_one.constprop.0+0x388): undefined reference to `ioport_map' This adds a Kconfig dependency. Fixes: 04c40f82ccc5 ("scsi: g_NCR5380: Merge g_NCR5380 and g_NCR5380_mmio drivers") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Acked-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
-
Hannes Reinecke authored
Found by 0-day robot. Fixes: a99ac6e715bc ("scsi: fcoe: set default TC priority") Signed-off-by: -
Arnd Bergmann authored
A recent bugfix introduced a harmless warning in the lpfc driver: drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_write_firmware': drivers/scsi/lpfc/lpfc_logmsg.h:56:45: error: format '%ld' expects argument of type 'long int', but argument 9 has type 'size_t {aka const unsigned int}' [-Werror=format=] 'size_t' is always the same width as 'long' in the kernel, but the compiler doesn't know that. The %z modifier is what the standard expects to be used here, and this shuts up the warning. Fixes: 679053c651fb ("scsi: lpfc: Fix fw download on SLI-4 FC adapters") Signed-off-by:Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Hannes Reinecke authored
Any multicase address is set on all interfaces, the base interface and any VLAN interfaces on top of this. So we might receive frames which are not destined for us. Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Hannes Reinecke authored
The FIP VLAN frame consists of an ethernet header followed by the FIP VLAN frame, so we need to skip the ethernet header if we want to check the FIP opcode. Signed-off-by:
-
Hannes Reinecke authored
Add additional statements for debugging FIP frames. Signed-off-by:
-
Hannes Reinecke authored
The 'enabled' sysfs attribute only accepts the values '0' and '1', so we should error out any other values. Signed-off-by:
-
Hannes Reinecke authored
If DCB is not enabled or compiled in we still should be setting a sane default priority. So put FCoE frames in priority class 'interactive' and FIP frames in priority class 'besteffort'. Signed-off-by:
-
Hannes Reinecke authored
We currently can only lookup the local xid, so we need to reject REC with empty rxid. Signed-off-by:
-
Hannes Reinecke authored
When detecting an out-of-order sequence we should be waiting for E_D_TOV before trying to abort the sequence. The response might still be stuck in the queue somewhere. Signed-off-by:
-
Hannes Reinecke authored
When we're receiving a timeout we should be checking for queue full status; if there are still some packets pending we should be resetting the counter to ensure we're not missing out any packets which are still queued. Signed-off-by:
-
Hannes Reinecke authored
When receiving packets from the network we cannot guarantee any frame ordering, so we should be receiving all valid frames and let the upper layers deal with it. Signed-off-by:
-
Hannes Reinecke authored
If a sequence should be aborted the exchange might already be completed (eg if the response is still queued in the rx queue), so this shouldn't considered as an error. Signed-off-by:
-
Hannes Reinecke authored
When a sequence times out we have no idea what happened to the frame. And we do not know if we will ever receive the frame. Hence we cannot re-use the xid as we would risk data corruption if the xid had been re-used and the timed out frame would be received after that. So we need to quarantine the xid until the lport is reset. Yes, I know this will (eventually) deplete the xid pool. But for now it's the safest method. Signed-off-by:
-
Hannes Reinecke authored
The cached exchange index might be invalid, in which case we should drop down to allocate a new one. And we should not try to access an invalid exchange when responding to a BA_ABTS. Signed-off-by:
-
Hannes Reinecke authored
When the queue depth is reduced we should print out the reason for this; it might be due to a queue full condition. Signed-off-by:
-
Hannes Reinecke authored
Occasionally it might happen that we receive a PRLI while we're still waiting for our PLOGI response. In that case we should return 'busy' LS status instead of 'plogi required' LS status. Signed-off-by:
-
Hannes Reinecke authored
PRLI is only required if the port is acting as an initiator; ports which support target functionality only do not need to send PRLI. At the same time the PRLI state is only used if the port initiated a PRLI transfer; if we received a PRLI request we should _not_ change the state as this would cause our PRLI response to be dropped. And when we receive a PRLI response we need to check if an image pair has been established; if not the remote port cannot act as a target for us and we need to disable target functionality. Signed-off-by:
-
Hannes Reinecke authored
The libfc stack generates an RTV request, so we should be implementing an RTV responder, too. Signed-off-by:
-
