Re: [PATCH v2 00/13] mpt3sas driver NVMe support:

2017-08-02 Thread Hannes Reinecke
On 08/02/2017 10:14 AM, Hannes Reinecke wrote:
> On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
>> Ventura Series controller are Tri-mode. The controller and
>> firmware are capable of supporting NVMe devices and
>> PCIe switches to be connected with the controller. This
>> patch set adds driver level support for NVMe devices and
>> PCIe switches.
>>
>> Suganath Prabu S (13):
>>   mpt3sas: Update MPI Header
>>   mpt3sas: Add nvme device support in slave alloc, target alloc and
>> probe
>>   mpt3sas: SGL to PRP Translation for I/Os to NVMe  devices
>>   mpt3sas: Added support for nvme encapsulated request message.
>>   mpt3sas: API 's to support NVMe drive addition to SML
>>   mpt3sas: API's to remove nvme drive from sml
>>   mpt3sas: Handle NVMe PCIe device related events generated
>>from firmware.
>>   mpt3sas: Set NVMe device queue depth as 128
>>   mpt3sas: scan and add nvme device after controller reset
>>   mpt3as: Add-Task-management-debug-info-for-NVMe-drives.
>>   mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log
>> info
>>   mpt3sas: Fix nvme drives checking for tlr.
>>   mpt3sas: Update mpt3sas driver version.
>>
>>  drivers/scsi/mpt3sas/mpi/mpi2.h  |   43 +-
>>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  647 ++-
>>  drivers/scsi/mpt3sas/mpi/mpi2_init.h |   11 +-
>>  drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  331 ++-
>>  drivers/scsi/mpt3sas/mpi/mpi2_pci.h  |  142 +++
>>  drivers/scsi/mpt3sas/mpi/mpi2_tool.h |   14 +-
>>  drivers/scsi/mpt3sas/mpt3sas_base.c  |  710 +++-
>>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  171 +++-
>>  drivers/scsi/mpt3sas/mpt3sas_config.c|  100 ++
>>  drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  158 ++-
>>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1874 
>> --
>>  drivers/scsi/mpt3sas/mpt3sas_warpdrive.c |2 +-
>>  12 files changed, 4063 insertions(+), 140 deletions(-)
>>  create mode 100644 drivers/scsi/mpt3sas/mpi/mpi2_pci.h
>>
> I'm not happy with this approach.
> NVMe devices should _not_ appear as SCSI devices; this will just confuse
> matters _and_ will be incompatible with 'normal' NVMe devices.
> 
> Rather I would like to see the driver to hook into the existing NVMe
> framework (which essentially means to treat the mpt3sas as a weird
> NVMe-over-Fabrics HBA), and expose the NVMe devices like any other NVMe HBA.
> 
> I'm sorry that you'll have to redo your patchset (again), but this is
> the only way I see how this patchset can be brought forward.
> 
> I'd be happy to discuss implementation details with you.
> 
After discussion with Broadcom it turns out that the NVMe passthrough
functionality of the current firmware is rather limited and wouldn't be
suitable for full NVMe device support.
And one of the goals is to have intermixed NVMe and SCSI support,
possibly with RAID thrown in for good measure.
So my idea of exposing the NVMe devices directly won't work, and I'll
have to retract my above comment.

But I'll continue to bug Broadcom; maybe we'll be getting NVMe device
support eventually :-)

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 13/13] mpt3sas: Update mpt3sas driver version.

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Updated mpt3sas driver version to 15.101.00.00
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index b7855c8..b705199 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -74,9 +74,9 @@
>  #define MPT3SAS_DRIVER_NAME  "mpt3sas"
>  #define MPT3SAS_AUTHOR "Avago Technologies 
> "
>  #define MPT3SAS_DESCRIPTION  "LSI MPT Fusion SAS 3.0 Device Driver"
> -#define MPT3SAS_DRIVER_VERSION   "15.100.00.00"
> +#define MPT3SAS_DRIVER_VERSION   "15.101.00.00"
>  #define MPT3SAS_MAJOR_VERSION15
> -#define MPT3SAS_MINOR_VERSION100
> +#define MPT3SAS_MINOR_VERSION101
>  #define MPT3SAS_BUILD_VERSION0
>  #define MPT3SAS_RELEASE_VERSION  00
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 11/13] mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log info

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> * Added debug prints for pcie devices in ioctl debug path. Which
> will be helpful for debugging.
> * Added PCIe device support for ioctl BTDHMAPPING ioctl.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c |   88 +++
>  1 files changed, 58 insertions(+), 30 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 12/13] mpt3sas: Fix nvme drives checking for tlr.

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Check for NVMe drives before enabling or checking tlr.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |   22 --
>  1 files changed, 16 insertions(+), 6 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 10/13] mpt3as: Add-Task-management-debug-info-for-NVMe-drives.

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Added debug information for NVMe/PCIe drives in target rest path.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |   83 -
>  1 files changed, 70 insertions(+), 13 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 09/13] mpt3sas: scan and add nvme device after controller reset

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> After Controller reset, Scan and add nvme device back to the topology.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  194 
> +-
>  1 files changed, 190 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index c5a131f..e3e803c 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -4869,6 +4869,7 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc, 
> struct scsi_cmnd *scmd,
>   char *desc_scsi_state = ioc->tmp_string;
>   u32 log_info = le32_to_cpu(mpi_reply->IOCLogInfo);
>   struct _sas_device *sas_device = NULL;
> + struct _pcie_device *pcie_device = NULL;
>   struct scsi_target *starget = scmd->device->sdev_target;
>   struct MPT3SAS_TARGET *priv_target = starget->hostdata;
>   char *device_str = NULL;
> @@ -5001,6 +5002,28 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc, 
> struct scsi_cmnd *scmd,
>   if (priv_target->flags & MPT_TARGET_FLAGS_VOLUME) {
>   pr_warn(MPT3SAS_FMT "\t%s wwid(0x%016llx)\n", ioc->name,
>   device_str, (unsigned long long)priv_target->sas_address);
> + } else if (priv_target->flags & MPT_TARGET_FLAGS_PCIE_DEVICE) {
> + pcie_device = mpt3sas_get_pdev_from_target(ioc, priv_target);
> + if (pcie_device) {
> + pr_info(MPT3SAS_FMT "\twwid(0x%016llx), port(%d)\n",
> + ioc->name,
> + (unsigned long long)pcie_device->wwid,
> + pcie_device->port_num);
> + if (pcie_device->enclosure_handle != 0)
> + pr_info(MPT3SAS_FMT
> + "\tenclosure logical id(0x%016llx), "
> + "slot(%d)\n", ioc->name,
> + (unsigned long long)
> + pcie_device->enclosure_logical_id,
> + pcie_device->slot);
> + if (pcie_device->connector_name[0])
> + pr_info(MPT3SAS_FMT
> + "\tenclosure level(0x%04x),"
> + "connector name( %s)\n",
> + ioc->name, pcie_device->enclosure_level,
> + pcie_device->connector_name);
> + pcie_device_put(pcie_device);
> + }
>   } else {
>   sas_device = mpt3sas_get_sdev_from_target(ioc, priv_target);
>   if (sas_device) {
> @@ -5047,11 +5070,10 @@ _scsih_scsi_ioc_info(struct MPT3SAS_ADAPTER *ioc, 
> struct scsi_cmnd *scmd,
>   struct sense_info data;
>   _scsih_normalize_sense(scmd->sense_buffer, &data);
>   pr_warn(MPT3SAS_FMT
> - "\t[sense_key,asc,ascq]: [0x%02x,0x%02x,0x%02x], 
> count(%d)\n",
> - ioc->name, data.skey,
> - data.asc, data.ascq, le32_to_cpu(mpi_reply->SenseCount));
> +   "\t[sense_key,asc,ascq]: [0x%02x,0x%02x,0x%02x], count(%d)\n",
> +   ioc->name, data.skey,
> +   data.asc, data.ascq, le32_to_cpu(mpi_reply->SenseCount));
>   }
> -
>   if (scsi_state & MPI2_SCSI_STATE_RESPONSE_INFO_VALID) {
>   response_info = le32_to_cpu(mpi_reply->ResponseInfo);
>   response_bytes = (u8 *)&response_info;
> @@ -8512,6 +8534,130 @@ _scsih_search_responding_sas_devices(struct 
> MPT3SAS_ADAPTER *ioc)
>  }
>  
>  /**
> + * _scsih_mark_responding_pcie_device - mark a pcie_device as responding
> + * @ioc: per adapter object
> + * @pcie_device_pg0: PCIe Device page 0
> + *
> + * After host reset, find out whether devices are still responding.
> + * Used in _scsih_remove_unresponding_devices.
> + *
> + * Return nothing.
> + */
> +static void
> +_scsih_mark_responding_pcie_device(struct MPT3SAS_ADAPTER *ioc,
> + Mpi26PCIeDevicePage0_t *pcie_device_pg0)
> +{
> + struct MPT3SAS_TARGET *sas_target_priv_data = NULL;
> + struct scsi_target *starget;
> + struct _pcie_device *pcie_device;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&ioc->pcie_device_lock, flags);
> + list_for_each_entry(pcie_device, &ioc->pcie_device_list, list) {
> + if ((pcie_device->wwid == pcie_device_pg0->WWID) &&
> + (pcie_device->slot == pcie_device_pg0->Slot)) {
> + pcie_device->responding = 1;
> + starget = pcie_device->starget;
> + if (starget && starget->hostdata) {
> + sas_target_priv_data = starget->hostdata;
> + sas_target_priv_data->tm_busy = 0;
> + sas_target_priv_data->deleted

Re: [PATCH v2 08/13] mpt3sas: Set NVMe device queue depth as 128

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Sets nvme device queue depth, name and displays device capabilities
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |2 +-
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |   40 
> ++
>  2 files changed, 41 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 0a8187e..b7855c8 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -115,7 +115,7 @@
>  
>  #define MPT3SAS_RAID_MAX_SECTORS 8192
>  #define MPT3SAS_HOST_PAGE_SIZE_4K12
> -
> +#define MPT3SAS_NVME_QUEUE_DEPTH 128
>  #define MPT_NAME_LENGTH  32  /* generic length of 
> strings */
>  #define MPT_STRING_LENGTH64
>  
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 1dd9674..c5a131f 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -2290,6 +2290,7 @@ scsih_slave_configure(struct scsi_device *sdev)
>   struct MPT3SAS_DEVICE *sas_device_priv_data;
>   struct MPT3SAS_TARGET *sas_target_priv_data;
>   struct _sas_device *sas_device;
> + struct _pcie_device *pcie_device;
>   struct _raid_device *raid_device;
>   unsigned long flags;
>   int qdepth;
> @@ -2420,6 +2421,45 @@ scsih_slave_configure(struct scsi_device *sdev)
>   }
>   }
>  
> + /* PCIe handling */
> + if (sas_target_priv_data->flags & MPT_TARGET_FLAGS_PCIE_DEVICE) {
> + spin_lock_irqsave(&ioc->pcie_device_lock, flags);
> + pcie_device = __mpt3sas_get_pdev_by_wwid(ioc,
> + sas_device_priv_data->sas_target->sas_address);
> + if (!pcie_device) {
> + spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
> + dfailprintk(ioc, pr_warn(MPT3SAS_FMT
> + "failure at %s:%d/%s()!\n", ioc->name, __FILE__,
> + __LINE__, __func__));
> + return 1;
> + }
> +
> + /*TODO-right Queue Depth?*/
> + qdepth = MPT3SAS_NVME_QUEUE_DEPTH;
> + ds = "NVMe";
> + /*TODO-Add device name when defined*/
> + sdev_printk(KERN_INFO, sdev,
> + "%s: handle(0x%04x), wwid(0x%016llx), port(%d)\n",
> + ds, handle, (unsigned long long)pcie_device->wwid,
> + pcie_device->port_num);
> + if (pcie_device->enclosure_handle != 0)
> + sdev_printk(KERN_INFO, sdev,
> + "%s: enclosure logical id(0x%016llx), slot(%d)\n",
> + ds,
> + (unsigned long long)pcie_device->enclosure_logical_id,
> + pcie_device->slot);
> + if (pcie_device->connector_name[0] != '\0')
> + sdev_printk(KERN_INFO, sdev,
> + "%s: enclosure level(0x%04x),"
> + "connector name( %s)\n", ds,
> + pcie_device->enclosure_level,
> + pcie_device->connector_name);
> + pcie_device_put(pcie_device);
> + spin_unlock_irqrestore(&ioc->pcie_device_lock, flags);
> + scsih_change_queue_depth(sdev, qdepth);
> + return 0;
> + }
> +
>   spin_lock_irqsave(&ioc->sas_device_lock, flags);
>   sas_device = __mpt3sas_get_sdev_by_addr(ioc,
>  sas_device_priv_data->sas_target->sas_address);
> 
Well; what are these TODOs doing here?
If you know things are not correct, why not doing them correctly?
If you cannot do them correctly, why?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 07/13] mpt3sas: Handle NVMe PCIe device related events generated from firmware.

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> * The controller firmware sends separate events for NVMe devices and
> PCIe switches similar to existing SAS events.
> 
> * NVMe device detection, addition and removal are reported by the
> firmware through PCIe Topology Change list events.
> 
> * The PCIe device state change events are sent when the firmware
> detects any abnormal conditions with a NVMe device or switch.
> 
> * The enumeration event are sent when the firmware starts PCIe device
> enumeration and stops.
> 
> * This patch has the code change to handle the events and add/remove
> NVMe devices in driver's inventory.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c  |   30 ++-
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  471 
> +-
>  2 files changed, 495 insertions(+), 6 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 06/13] mpt3sas: API's to remove nvme drive from sml

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Below API's are included in nvme drive remove path.
> _scsih_pcie_device_remove_by_handle
> _scsih_pcie_device_remove_from_sml
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  148 
> +-
>  1 files changed, 145 insertions(+), 3 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 05/13] mpt3sas: API 's to support NVMe drive addition to SML

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Below Functions are added in various paths to support NVMe
> drive addition.
> 
> _scsih_pcie_add_device
> _scsih_pcie_device_add
> _scsih_pcie_device_init_add
> _scsih_check_pcie_access_status
> _scsih_pcie_check_device
> 
> mpt3sas_get_pdev_by_handle
> 
> mpt3sas_config_get_pcie_device_pg0
> mpt3sas_config_get_pcie_device_pg2
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h   |   10 +
>  drivers/scsi/mpt3sas/mpt3sas_config.c |  100 +++
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c  |  473 
> -
>  3 files changed, 575 insertions(+), 8 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 04/13] mpt3sas: Added support for nvme encapsulated request message.

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> * Mpt3sas driver uses the NVMe Encapsulated Request message to
> send an NVMe command to an NVMe device attached to the IOC.
> 
> * Normal I/O commands like reads and writes are passed to the
> controller as SCSI commands and the controller has the ability
> to translate the commands to NVMe equivalent.
> 
> * This encapsulated NVMe command is used by applications to send
> direct NVMe commands to NVMe drives or for handling unmap where
> the translation at controller/firmware level is having
> performance issues.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.c |   56 -
>  drivers/scsi/mpt3sas/mpt3sas_base.h |1 +
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c  |   69 
> ---
>  3 files changed, 119 insertions(+), 7 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 02/13] mpt3sas: Add nvme device support in slave alloc, target alloc and probe

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> 1) Added support for probing pcie device and adding NVMe drives to
> SML and driver's internal list pcie_device_list.
> 
> 2) Added support for determing NVMe as boot device.
> 
> 3) Added nvme device support for call back functions scan_finished
> target_alloc,slave_alloc,target destroy and slave destroy.
> 
>  a) During scan, pcie devices are probed and added to SML to drivers
> internal list.
> 
>  b) target_alloc & slave alloc API's allocates resources for
> (MPT3SAS_TARGET & MPT3SAS_DEVICE) private datas and holds
> information like handle, target_id etc.
> 
>  c) slave_destroy & target_destroy are called when driver unregisters
> or removes device. Also frees allocated resources and info.
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  110 -
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c |  431 
> +++---
>  2 files changed, 507 insertions(+), 34 deletions(-)
> 
Have you considered using 'scan_start()/scan_finished()' SCSI midlayer
callbacks here?
Seeing that you are enumerating the devices internally already that
should give you better control about the scanning process.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [PATCH v2 01/13] mpt3sas: Update MPI Header

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Update MPI Files for NVMe support
> 
> Signed-off-by: Chaitra P B 
> Signed-off-by: Suganath Prabu S 
> ---
>  drivers/scsi/mpt3sas/mpi/mpi2.h  |   43 +++-
>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  647 
> +-
>  drivers/scsi/mpt3sas/mpi/mpi2_init.h |   11 +-
>  drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  331 +-
>  drivers/scsi/mpt3sas/mpi/mpi2_pci.h  |  142 
>  drivers/scsi/mpt3sas/mpi/mpi2_tool.h |   14 +-
>  6 files changed, 1177 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/scsi/mpt3sas/mpi/mpi2_pci.h
> 
> diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
> index a9a659f..bc59058 100644
> --- a/drivers/scsi/mpt3sas/mpi/mpi2.h
> +++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
> @@ -8,7 +8,7 @@
>   * scatter/gather formats.
>   * Creation Date:  June 21, 2006
>   *
> - * mpi2.h Version:  02.00.42
> + * mpi2.h Version:  02.00.48
>   *
>   * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
>   *   prefix are for use only on MPI v2.5 products, and must not be used
> @@ -103,6 +103,16 @@
>   * 08-25-15  02.00.40  Bumped MPI2_HEADER_VERSION_UNIT.
>   * 12-15-15  02.00.41  Bumped MPI_HEADER_VERSION_UNIT
>   * 01-01-16  02.00.42  Bumped MPI_HEADER_VERSION_UNIT
> + * 04-05-16  02.00.43  Modified  MPI26_DIAG_BOOT_DEVICE_SELECT defines
> + * to be unique within first 32 characters.
> + * Removed AHCI support.
> + * Removed SOP support.
> + * Bumped MPI2_HEADER_VERSION_UNIT.
> + * 04-10-16  02.00.44  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 07-06-16  02.00.45  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 09-02-16  02.00.46  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 11-23-16  02.00.47  Bumped MPI2_HEADER_VERSION_UNIT.
> + * 02-03-17  02.00.48  Bumped MPI2_HEADER_VERSION_UNIT.
>   * --
>   */
>  
> @@ -142,7 +152,7 @@
>  #define MPI2_VERSION_02_06   (0x0206)
>  
>  /*Unit and Dev versioning for this MPI header set */
> -#define MPI2_HEADER_VERSION_UNIT(0x2A)
> +#define MPI2_HEADER_VERSION_UNIT(0x30)
>  #define MPI2_HEADER_VERSION_DEV (0x00)
>  #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
>  #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
> @@ -249,6 +259,12 @@ typedef volatile struct _MPI2_SYSTEM_INTERFACE_REGS {
>  #define MPI2_DIAG_BOOT_DEVICE_SELECT_DEFAULT(0x)
>  #define MPI2_DIAG_BOOT_DEVICE_SELECT_HCDW   (0x0800)
>  
> +/* Defines for V7A/V7R HostDiagnostic Register */
> +#define MPI26_DIAG_BOOT_DEVICE_SEL_64FLASH  (0x)
> +#define MPI26_DIAG_BOOT_DEVICE_SEL_64HCDW   (0x0800)
> +#define MPI26_DIAG_BOOT_DEVICE_SEL_32FLASH  (0x1000)
> +#define MPI26_DIAG_BOOT_DEVICE_SEL_32HCDW   (0x1800)
> +
>  #define MPI2_DIAG_CLEAR_FLASH_BAD_SIG   (0x0400)
>  #define MPI2_DIAG_FORCE_HCB_ON_RESET(0x0200)
>  #define MPI2_DIAG_HCB_MODE  (0x0100)
> @@ -367,6 +383,7 @@ typedef struct _MPI2_DEFAULT_REQUEST_DESCRIPTOR {
>  #define MPI2_REQ_DESCRIPT_FLAGS_DEFAULT_TYPE(0x08)
>  #define MPI2_REQ_DESCRIPT_FLAGS_RAID_ACCELERATOR(0x0A)
>  #define MPI25_REQ_DESCRIPT_FLAGS_FAST_PATH_SCSI_IO  (0x0C)
> +#define MPI26_REQ_DESCRIPT_FLAGS_PCIE_ENCAPSULATED  (0x10)
>  
>  #define MPI2_REQ_DESCRIPT_FLAGS_IOC_FIFO_MARKER (0x01)
>  
> @@ -425,6 +442,13 @@ typedef MPI2_SCSI_IO_REQUEST_DESCRIPTOR
>   Mpi25FastPathSCSIIORequestDescriptor_t,
>   *pMpi25FastPathSCSIIORequestDescriptor_t;
>  
> +/*PCIe Encapsulated Request Descriptor */
> +typedef MPI2_SCSI_IO_REQUEST_DESCRIPTOR
> + MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR,
> + *PTR_MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR,
> + Mpi26PCIeEncapsulatedRequestDescriptor_t,
> + *pMpi26PCIeEncapsulatedRequestDescriptor_t;
> +
>  /*union of Request Descriptors */
>  typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
>   MPI2_DEFAULT_REQUEST_DESCRIPTOR Default;
> @@ -433,6 +457,7 @@ typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
>   MPI2_SCSI_TARGET_REQUEST_DESCRIPTOR SCSITarget;
>   MPI2_RAID_ACCEL_REQUEST_DESCRIPTOR RAIDAccelerator;
>   MPI25_FP_SCSI_IO_REQUEST_DESCRIPTOR FastPathSCSIIO;
> + MPI26_PCIE_ENCAPSULATED_REQUEST_DESCRIPTOR PCIeEncapsulated;
>   U64 Words;
>  } MPI2_REQUEST_DESCRIPTOR_UNION,
>   *PTR_MPI2_REQUEST_DESCRIPTOR_UNION,
> @@ -450,6 +475,7 @@ typedef union _MPI2_REQUEST_DESCRIPTOR_UNION {
>   *  Atomic SCSI Target Request Descriptor
>   *  Atomic RAID Accelerator Request Descriptor
>   *  Atomic Fast Path SCSI IO Request Descriptor
> + *  Atomic PCIe Encapsulated Request Descriptor
>   */
>  
>  /*Atomic Request Descriptor */
> @@ -487,6 +513,7 @@ typedef struct _MPI2_DEFAULT_REPLY_DESCRIPTOR {
>  #define MPI2_RPY_

Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

2017-08-02 Thread Ming Lei
On Thu, Aug 03, 2017 at 01:35:29AM +, Bart Van Assche wrote:
> On Wed, 2017-08-02 at 11:31 +0800, Ming Lei wrote:
> > On Tue, Aug 01, 2017 at 03:11:42PM +, Bart Van Assche wrote:
> > > On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote:
> > > > On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote:
> > > > > How can we get the accurate 'number of requests in progress' 
> > > > > efficiently?
> > > 
> > > Hello Ming,
> > > 
> > > How about counting the number of bits that have been set in the tag set?
> > > I am aware that these bits can be set and/or cleared concurrently with the
> > > dispatch code but that count is probably a good starting point.
> > 
> > It has to be atomic_t, which is too too heavy for us, please see the report:
> > 
> > http://marc.info/?t=14986844843&r=1&w=2
> > 
> > Both Jens and I want to kill hd_struct.in_flight, but looks still no
> > good way. 
> 
> Hello Ming,
> 
> Sorry but I disagree that a new atomic variable should be added to keep track
> of the number of busy requests. Counting the number of bits that are set in
> the tag set should be good enough in this context.

That won't work because the tag set is host wide and shared by all LUNs.


-- 
Ming


Re: [PATCH 04/14] blk-mq-sched: improve dispatching from sw queue

2017-08-02 Thread Bart Van Assche
On Wed, 2017-08-02 at 11:31 +0800, Ming Lei wrote:
> On Tue, Aug 01, 2017 at 03:11:42PM +, Bart Van Assche wrote:
> > On Tue, 2017-08-01 at 18:50 +0800, Ming Lei wrote:
> > > On Tue, Aug 01, 2017 at 06:17:18PM +0800, Ming Lei wrote:
> > > > How can we get the accurate 'number of requests in progress' 
> > > > efficiently?
> > 
> > Hello Ming,
> > 
> > How about counting the number of bits that have been set in the tag set?
> > I am aware that these bits can be set and/or cleared concurrently with the
> > dispatch code but that count is probably a good starting point.
> 
> It has to be atomic_t, which is too too heavy for us, please see the report:
> 
>   http://marc.info/?t=14986844843&r=1&w=2
> 
> Both Jens and I want to kill hd_struct.in_flight, but looks still no
> good way. 

Hello Ming,

Sorry but I disagree that a new atomic variable should be added to keep track
of the number of busy requests. Counting the number of bits that are set in
the tag set should be good enough in this context.

Thanks,

Bart.

Re: [PATCH 05/14] blk-mq-sched: don't dequeue request until all in ->dispatch are flushed

2017-08-02 Thread Bart Van Assche
On Wed, 2017-08-02 at 11:01 +0800, Ming Lei wrote:
> On Tue, Aug 01, 2017 at 04:14:07PM +, Bart Van Assche wrote:
> > On Tue, 2017-08-01 at 18:44 +0800, Ming Lei wrote:
> > > On Mon, Jul 31, 2017 at 11:42:21PM +, Bart Van Assche wrote:
> > > > Since setting, clearing and testing of BLK_MQ_S_BUSY can happen 
> > > > concurrently
> > > > and since clearing and testing happens without any locks held I'm 
> > > > afraid this
> > > > patch introduces the following race conditions:
> > > > [ ... ]
> > > > * Checking BLK_MQ_S_BUSY after requests have been removed from the 
> > > > dispatch list
> > > >   but before that bit is cleared, resulting in test_bit(BLK_MQ_S_BUSY, 
> > > > &hctx->state)
> > > >   reporting that the BLK_MQ_S_BUSY
> > > > has been set although there are no requests
> > > >   on the dispatch list.
> > > 
> > > That won't be a problem, because dispatch will be started in the
> > > context in which dispatch list is flushed, since the BUSY bit
> > > is cleared after blk_mq_dispatch_rq_list() returns. So no I/O
> > > hang.
> > 
> > Hello Ming,
> > 
> > Please consider changing the name of the BLK_MQ_S_BUSY constant. That bit
> > is used to serialize dispatching requests from the hctx dispatch list but
> > that's not clear from the name of that constant.
> 
> Actually what we want to do is to stop taking request from sw/scheduler
> queue when ->dispatch aren't flushed completely, I think BUSY isn't
> a bad name for this case, or how about DISPATCH_BUSY? or
> FLUSHING_DISPATCH?

Hello Ming,

FLUSHING_DISPATCH sounds fine to me. In case you would prefer a shorter name,
how about BLK_MQ_S_DISPATCHING (refers to dispatching requests to the driver)?

Bart.

[PATCH 20/21] lpfc: Add new adapter type 6 support

2017-08-02 Thread James Smart
The new adpater has a different PCI bar map, the EQ/CQ doorbell
registers and their formats are different from LPE1600 /LPE3200

Replaced the field EQCQDBregaddr with EQDBregaddr and CQDBregaddr in
lpfc_sli4_hba structure. There were a few other minor changes to support
the new adapter type.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_debugfs.c |  20 +-
 drivers/scsi/lpfc/lpfc_debugfs.h |  11 +-
 drivers/scsi/lpfc/lpfc_hw4.h |  85 -
 drivers/scsi/lpfc/lpfc_init.c| 152 +--
 drivers/scsi/lpfc/lpfc_nvme.c|   4 +-
 drivers/scsi/lpfc/lpfc_nvmet.c   |   5 +-
 drivers/scsi/lpfc/lpfc_sli.c | 402 +++
 drivers/scsi/lpfc/lpfc_sli4.h|  27 ++-
 8 files changed, 543 insertions(+), 163 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index c292264aa687..e900d0a3a0fd 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -3900,10 +3900,15 @@ lpfc_idiag_drbacc_read_reg(struct lpfc_hba *phba, char 
*pbuffer,
return 0;
 
switch (drbregid) {
-   case LPFC_DRB_EQCQ:
-   len += snprintf(pbuffer+len, LPFC_DRB_ACC_BUF_SIZE-len,
-   "EQCQ-DRB-REG: 0x%08x\n",
-   readl(phba->sli4_hba.EQCQDBregaddr));
+   case LPFC_DRB_EQ:
+   len += snprintf(pbuffer+len, LPFC_DRB_ACC_BUF_SIZE - len,
+   "EQ-DRB-REG: 0x%08x\n",
+   readl(phba->sli4_hba.EQDBregaddr));
+   break;
+   case LPFC_DRB_CQ:
+   len += snprintf(pbuffer + len, LPFC_DRB_ACC_BUF_SIZE - len,
+   "CQ-DRB-REG: 0x%08x\n",
+   readl(phba->sli4_hba.CQDBregaddr));
break;
case LPFC_DRB_MQ:
len += snprintf(pbuffer+len, LPFC_DRB_ACC_BUF_SIZE-len,
@@ -4042,8 +4047,11 @@ lpfc_idiag_drbacc_write(struct file *file, const char 
__user *buf,
idiag.cmd.opcode == LPFC_IDIAG_CMD_DRBACC_ST ||
idiag.cmd.opcode == LPFC_IDIAG_CMD_DRBACC_CL) {
switch (drb_reg_id) {
-   case LPFC_DRB_EQCQ:
-   drb_reg = phba->sli4_hba.EQCQDBregaddr;
+   case LPFC_DRB_EQ:
+   drb_reg = phba->sli4_hba.EQDBregaddr;
+   break;
+   case LPFC_DRB_CQ:
+   drb_reg = phba->sli4_hba.CQDBregaddr;
break;
case LPFC_DRB_MQ:
drb_reg = phba->sli4_hba.MQDBregaddr;
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.h b/drivers/scsi/lpfc/lpfc_debugfs.h
index 7b7d314af0e0..97674e86dba7 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.h
+++ b/drivers/scsi/lpfc/lpfc_debugfs.h
@@ -126,12 +126,13 @@
 #define LPFC_DRB_ACC_WR_CMD_ARG 2
 #define LPFC_DRB_ACC_BUF_SIZE 256
 
-#define LPFC_DRB_EQCQ 1
-#define LPFC_DRB_MQ   2
-#define LPFC_DRB_WQ   3
-#define LPFC_DRB_RQ   4
+#define LPFC_DRB_EQ   1
+#define LPFC_DRB_CQ   2
+#define LPFC_DRB_MQ   3
+#define LPFC_DRB_WQ   4
+#define LPFC_DRB_RQ   5
 
-#define LPFC_DRB_MAX  4
+#define LPFC_DRB_MAX  5
 
 #define IDIAG_DRBACC_REGID_INDX 0
 #define IDIAG_DRBACC_VALUE_INDX 1
diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h
index 1db0a38683f4..c18f83d4bdec 100644
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -84,6 +84,7 @@ struct lpfc_sli_intf {
 #define LPFC_SLI_INTF_IF_TYPE_00
 #define LPFC_SLI_INTF_IF_TYPE_11
 #define LPFC_SLI_INTF_IF_TYPE_22
+#define LPFC_SLI_INTF_IF_TYPE_66
 #define lpfc_sli_intf_sli_family_SHIFT 8
 #define lpfc_sli_intf_sli_family_MASK  0x000F
 #define lpfc_sli_intf_sli_family_WORD  word0
@@ -731,11 +732,13 @@ struct lpfc_register {
  * register sets depending on the UCNA Port's reported if_type
  * value.  For UCNA ports running SLI4 and if_type 0, they reside in
  * BAR4.  For UCNA ports running SLI4 and if_type 2, they reside in
- * BAR0.  The offsets are the same so the driver must account for
- * any base address difference.
+ * BAR0.  For FC ports running SLI4 and if_type 6, they reside in
+ * BAR2. The offsets and base address are different,  so the driver
+ * has to compute the register addresses accordingly
  */
 #define LPFC_ULP0_RQ_DOORBELL  0x00A0
 #define LPFC_ULP1_RQ_DOORBELL  0x00C0
+#define LPFC_IF6_RQ_DOORBELL   0x0080
 #define lpfc_rq_db_list_fm_num_posted_SHIFT24
 #define lpfc_rq_db_list_fm_num_posted_MASK 0x00FF
 #define lpfc_rq_db_list_fm_num_posted_WORD word0
@@ -770,6 +773,20 @@ struct lpfc_register {
 #define lpfc_wq_db_ring_fm_id_MASK  0x
 #define lpfc_wq_db_ring_fm_id_WORD  word0
 
+#define LPFC_IF6_WQ_DOORBELL   0x0040
+#define lpfc_if6_wq_db_list_fm_num_posted_S

[PATCH 14/21] lpfc: Fix MRQ > 1 context list handling

2017-08-02 Thread James Smart
From: Dick Kennedy 

Various oops including cpu LOCKUPs were seen.

For asynchronously received ius where the driver must assign
exchange resources, the resources were on a single get (free) list
and put list (finished, waiting to be put on get list). As all cpus
are sharing the lists, an interrupt for a receive frame may have to
wait for all the other cpus to place their done work onto the put
list before it can acquire the lock to pull from the list.

Fix by breaking the resource lists into per-cpu lists or at least
more than 1 list with cpu's sharing the lists). A cpu would allocate
from the free list for its own cpu, and put its done work on the its own
put list - avoiding the contention. As cpu load may vary, when empty, a
cpu may grab from another cpu, thereby changing resource distribution.
But searching for a resource only occurs on 1 or a few cpus until a
single resource can be allocated. if the condition reoccurs, it starts
looking at a different cpu.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_attr.c|  11 +-
 drivers/scsi/lpfc/lpfc_crtn.h|   5 +-
 drivers/scsi/lpfc/lpfc_debugfs.c |  11 +-
 drivers/scsi/lpfc/lpfc_init.c|  18 ++-
 drivers/scsi/lpfc/lpfc_nvmet.c   | 265 ++-
 drivers/scsi/lpfc/lpfc_nvmet.h   |  14 +++
 drivers/scsi/lpfc/lpfc_sli.c |   2 +-
 drivers/scsi/lpfc/lpfc_sli4.h|   7 +-
 8 files changed, 236 insertions(+), 97 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 4ed48ed38e79..d3d01ff44423 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -245,13 +245,10 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
atomic_read(&tgtp->xmt_abort_rsp),
atomic_read(&tgtp->xmt_abort_rsp_error));
 
-   spin_lock(&phba->sli4_hba.nvmet_ctx_get_lock);
-   spin_lock(&phba->sli4_hba.nvmet_ctx_put_lock);
-   tot = phba->sli4_hba.nvmet_xri_cnt -
-   (phba->sli4_hba.nvmet_ctx_get_cnt +
-   phba->sli4_hba.nvmet_ctx_put_cnt);
-   spin_unlock(&phba->sli4_hba.nvmet_ctx_put_lock);
-   spin_unlock(&phba->sli4_hba.nvmet_ctx_get_lock);
+   /* Calculate outstanding IOs */
+   tot = atomic_read(&tgtp->rcv_fcp_cmd_drop);
+   tot += atomic_read(&tgtp->xmt_fcp_release);
+   tot = atomic_read(&tgtp->rcv_fcp_cmd_in) - tot;
 
len += snprintf(buf + len, PAGE_SIZE - len,
"IO_CTX: %08x  WAIT: cur %08x tot %08x\n"
diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h
index da669dce12fe..7e300734b345 100644
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -556,9 +556,8 @@ int lpfc_nvmet_update_targetport(struct lpfc_hba *phba);
 void lpfc_nvmet_destroy_targetport(struct lpfc_hba *phba);
 void lpfc_nvmet_unsol_ls_event(struct lpfc_hba *phba,
struct lpfc_sli_ring *pring, struct lpfc_iocbq *piocb);
-void lpfc_nvmet_unsol_fcp_event(struct lpfc_hba *phba,
-   struct lpfc_sli_ring *pring,
-   struct rqb_dmabuf *nvmebuf, uint64_t isr_ts);
+void lpfc_nvmet_unsol_fcp_event(struct lpfc_hba *phba, uint32_t idx,
+   struct rqb_dmabuf *nvmebuf, uint64_t isr_ts);
 void lpfc_nvme_mod_param_dep(struct lpfc_hba *phba);
 void lpfc_nvme_abort_fcreq_cmpl(struct lpfc_hba *phba,
struct lpfc_iocbq *cmdiocb,
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index 5cc8b0f7d885..c292264aa687 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -848,13 +848,10 @@ lpfc_debugfs_nvmestat_data(struct lpfc_vport *vport, char 
*buf, int size)
spin_unlock(&phba->sli4_hba.abts_nvme_buf_list_lock);
}
 
-   spin_lock(&phba->sli4_hba.nvmet_ctx_get_lock);
-   spin_lock(&phba->sli4_hba.nvmet_ctx_put_lock);
-   tot = phba->sli4_hba.nvmet_xri_cnt -
-   (phba->sli4_hba.nvmet_ctx_get_cnt +
-   phba->sli4_hba.nvmet_ctx_put_cnt);
-   spin_unlock(&phba->sli4_hba.nvmet_ctx_put_lock);
-   spin_unlock(&phba->sli4_hba.nvmet_ctx_get_lock);
+   /* Calculate outstanding IOs */
+   tot = atomic_read(&tgtp->rcv_fcp_cmd_drop);
+   tot += atomic_read(&tgtp->xmt_fcp_release);
+   tot = atomic_read(&tgtp->rcv_fcp_cmd_in) - tot;
 
len += snprintf(buf + len, size - len,
"IO_CTX: %08x  WAIT: cur %08x tot %08x\n"
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 5f32a7fe169d..897eb62ed4e6 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/driver

[PATCH 07/21] lpfc: Correct return error codes to align with nvme_fc transport

2017-08-02 Thread James Smart
From: Dick Kennedy 

Modify driver return error codes to align with host nvme transport.

Driver isn't returning Exxx error codes to properly reflect out of
resource or connectivity conditions (-EBUSY), yet there were hard
error conditions returning -EBUSY.

Fix to return:
temporary failures or temporary resource availability: -EBUSY
Connectivity issues: -ENODEV
all others are treated as hard errors and return an -Exxx value
that indicates the type of error.

Also, lpfc_sli4_issue_wqe() was modified to not translate error
from -Exxx to WQE state.  This allows lpfc_nvme_fcp_io_submit()
routine to just return whatever -E value was returned from other
routines.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvme.c |  9 -
 drivers/scsi/lpfc/lpfc_sli.c  | 23 ++-
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 2f50df6a3dca..87e0743c4ace 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -364,7 +364,7 @@ lpfc_nvme_gen_req(struct lpfc_vport *vport, struct 
lpfc_dmabuf *bmp,
 genwqe->sli4_xritag, genwqe->iotag, ndlp->nlp_DID);
 
rc = lpfc_sli4_issue_wqe(phba, LPFC_ELS_RING, genwqe);
-   if (rc == WQE_ERROR) {
+   if (rc) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_ELS,
 "6045 Issue GEN REQ WQE to NPORT x%x "
 "Data: x%x x%x\n",
@@ -1270,7 +1270,7 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port 
*pnvme_lport,
 * not exceed the programmed depth.
 */
if (atomic_read(&ndlp->cmd_pending) >= ndlp->cmd_qdepth) {
-   ret = -EAGAIN;
+   ret = -EBUSY;
goto out_fail;
}
 
@@ -1279,7 +1279,7 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port 
*pnvme_lport,
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR,
 "6065 driver's buffer pool is empty, "
 "IO failed\n");
-   ret = -ENOMEM;
+   ret = -EBUSY;
goto out_fail;
}
 #ifdef CONFIG_SCSI_LPFC_DEBUG_FS
@@ -1332,7 +1332,6 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port 
*pnvme_lport,
 "sid: x%x did: x%x oxid: x%x\n",
 ret, vport->fc_myDID, ndlp->nlp_DID,
 lpfc_ncmd->cur_iocbq.sli4_xritag);
-   ret = -EBUSY;
goto out_free_nvme_buf;
}
 
@@ -1576,7 +1575,7 @@ lpfc_nvme_fcp_abort(struct nvme_fc_local_port 
*pnvme_lport,
abts_buf->wqe_cmpl = lpfc_nvme_abort_fcreq_cmpl;
ret_val = lpfc_sli4_issue_wqe(phba, LPFC_FCP_RING, abts_buf);
spin_unlock_irqrestore(&phba->hbalock, flags);
-   if (ret_val == IOCB_ERROR) {
+   if (ret_val) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_ABTS,
 "6137 Failed abts issue_wqe with status x%x "
 "for nvme_fcreq %p.\n",
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 0615bf9def23..8476e3d249b0 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -106,7 +106,7 @@ lpfc_get_iocb_from_iocbq(struct lpfc_iocbq *iocbq)
  * -ENOMEM.
  * The caller is expected to hold the hbalock when calling this routine.
  **/
-static uint32_t
+static int
 lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe *wqe)
 {
union lpfc_wqe *temp_wqe;
@@ -123,7 +123,7 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe *wqe)
idx = ((q->host_index + 1) % q->entry_count);
if (idx == q->hba_index) {
q->WQ_overflow++;
-   return -ENOMEM;
+   return -EBUSY;
}
q->WQ_posted++;
/* set consumption flag every once in a while */
@@ -10741,7 +10741,7 @@ lpfc_sli4_abort_nvme_io(struct lpfc_hba *phba, struct 
lpfc_sli_ring *pring,
abtsiocbp->vport = vport;
abtsiocbp->wqe_cmpl = lpfc_nvme_abort_fcreq_cmpl;
retval = lpfc_sli4_issue_wqe(phba, LPFC_FCP_RING, abtsiocbp);
-   if (retval == IOCB_ERROR) {
+   if (retval) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME,
 "6147 Failed abts issue_wqe with status x%x "
 "for oxid x%x\n",
@@ -18891,6 +18891,7 @@ lpfc_sli4_issue_wqe(struct lpfc_hba *phba, uint32_t 
ring_number,
struct lpfc_sglq *sglq;
struct lpfc_sli_ring *pring;
unsigned long iflags;
+   uint32_t ret = 0;
 
/* NVME_LS and NVME_LS ABTS requests. */
if (pwqe->iocb_flag & LPFC_IO_NVME_LS) {
@@ -18909,10 +18910,12 @@ lpfc_sli4_issue_wqe(struct lpfc_hba *phba, uint32_t 
ring_number,
}
bf_set(wqe_xri_tag, &pwqe->wqe.xmit_bls_rsp.wqe_com,

[PATCH 02/21] lpfc: Fix plogi collision that causes illegal state transition

2017-08-02 Thread James Smart
From: Dick Kennedy 

Message "0271 Illegal State Transition: node" seen in logs, all
luns are unuseable for that target.

A window exists in the rcv_plogi path where if the state is plogi
issue but the driver has not issued a plogi, then two reglogins will
be sent for the same RPI. The first one to complete will advance
the state to prli issue the second one will be detected as an
illegal state, and leave the node in an unusable state.

Correct the completion routine for the PLOGI ACC that detects the
state change when the driver starts discovery on the node again
and drop the REGLOGIN mailbox command.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_els.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 6d1d6f691df4..9e9aa8bb7001 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -3930,7 +3930,31 @@ lpfc_cmpl_els_rsp(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
if (mbox) {
if ((rspiocb->iocb.ulpStatus == 0)
&& (ndlp->nlp_flag & NLP_ACC_REGLOGIN)) {
-   lpfc_unreg_rpi(vport, ndlp);
+   if (!lpfc_unreg_rpi(vport, ndlp)) {
+   if (ndlp->nlp_state ==  NLP_STE_PLOGI_ISSUE ||
+   ndlp->nlp_state ==
+NLP_STE_REG_LOGIN_ISSUE) {
+   lpfc_printf_vlog(vport, KERN_INFO,
+LOG_DISCOVERY,
+"0314 PLOGI recov "
+"DID x%x "
+"Data: x%x x%x x%x\n",
+ndlp->nlp_DID,
+ndlp->nlp_state,
+ndlp->nlp_rpi,
+ndlp->nlp_flag);
+   mp = (struct lpfc_dmabuf *)
+ mbox->context1;
+   if (mp) {
+   lpfc_mbuf_free(phba, mp->virt,
+  mp->phys);
+   kfree(mp);
+   }
+   mempool_free(mbox, phba->mbox_mem_pool);
+   goto out;
+   }
+   }
+
/* Increment reference count to ndlp to hold the
 * reference to ndlp for the callback function.
 */
-- 
2.13.1



[PATCH 03/21] lpfc: Fix loop mode target discovery

2017-08-02 Thread James Smart
From: Dick Kennedy 

The driver does not discover targets when in loop mode.

The NLP type is correctly getting set when a fabric connection is
detected but, not for loop. The unknown NLP type means that the
driver does not issue a PRLI when in loop topology. Thus target
discovery fails.

Fix by checking the topology during discovery.  If it is loop,
set the NLP FC4 type to FCP.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nportdisc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c 
b/drivers/scsi/lpfc/lpfc_nportdisc.c
index f74cb0142fd4..95b2b43ac37d 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1724,6 +1724,9 @@ lpfc_cmpl_reglogin_reglogin_issue(struct lpfc_vport 
*vport,
lpfc_nvme_update_localport(vport);
}
 
+   } else if (phba->fc_topology == LPFC_TOPOLOGY_LOOP) {
+   ndlp->nlp_fc4_type |= NLP_FC4_FCP;
+
} else if (ndlp->nlp_fc4_type == 0) {
rc = lpfc_ns_cmd(vport, SLI_CTNS_GFT_ID,
 0, ndlp->nlp_DID);
-- 
2.13.1



[PATCH 12/21] lpfc: Correct issues with FAWWN and FDISCs

2017-08-02 Thread James Smart
From: Dick Kennedy 

When using fabric-assigned WWNs, the switch doesn't like copy of
the FLOGI payload, which includes valid VVL bits, to be used as
the FDISC paylaod.

Rather than wait for corrected switch firmware, ensure the VVL bits
are marked invalid on FDISCs.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_els.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 9a8808abe61f..f97d578ea6bd 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -8868,6 +8868,7 @@ lpfc_issue_els_fdisc(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp,
pcmd += sizeof(uint32_t); /* Node Name */
pcmd += sizeof(uint32_t); /* Node Name */
memcpy(pcmd, &vport->fc_nodename, 8);
+   sp->cmn.valid_vendor_ver_level = 0;
memset(sp->un.vendorVersion, 0, sizeof(sp->un.vendorVersion));
lpfc_set_disctmo(vport);
 
-- 
2.13.1



[PATCH 11/21] lpfc: Fix NVME PRLI handling during RSCN

2017-08-02 Thread James Smart
From: Dick Kennedy 

A race condition was found whereby the initiator would receive
the RSCN for a new NVME device before it had a chance to register
its FC4 support with the fabric. Thus, when queried by the initiator,
it would see that the target supported FC-NVME.

Corrected by making the assumption that the target always supports
FC-NVME thus a PRLI is sent. It's ok for the target to reject it.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_els.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index fe0dd42b75af..9a8808abe61f 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -2177,6 +2177,16 @@ lpfc_issue_els_prli(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp,
uint16_t cmdsize;
u32 local_nlp_type, elscmd;
 
+   /*
+* If we are in RSCN mode, the FC4 types supported from a
+* previous GFT_ID command may not be accurate. So, if we
+* are a NVME Initiator, always look for the possibility of
+* the remote NPort beng a NVME Target.
+*/
+   if (phba->sli_rev == LPFC_SLI_REV4 &&
+   vport->fc_flag & FC_RSCN_MODE &&
+   vport->nvmei_support)
+   ndlp->nlp_fc4_type |= NLP_FC4_NVME;
local_nlp_type = ndlp->nlp_fc4_type;
 
  send_next_prli:
-- 
2.13.1



[PATCH 16/21] lpfc: Fix nvme target failure after 2nd adapter reset

2017-08-02 Thread James Smart
From: Dick Kennedy 

Fix nvme target failure after 2nd adapter reset

The nonrecovery occurred because the lpfc nvme initiator
function did not reestablish its localport creation with the nvme
host transport in lpfc_oneline.  Because of that, an NVME rport
binding could not take place.

Corrected by recreating the localport in the adapter reset recovery
routine.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_init.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 897eb62ed4e6..659662777b65 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3048,7 +3048,7 @@ lpfc_online(struct lpfc_hba *phba)
 {
struct lpfc_vport *vport;
struct lpfc_vport **vports;
-   int i;
+   int i, error = 0;
bool vpis_cleared = false;
 
if (!phba)
@@ -3072,6 +3072,22 @@ lpfc_online(struct lpfc_hba *phba)
if (!phba->sli4_hba.max_cfg_param.vpi_used)
vpis_cleared = true;
spin_unlock_irq(&phba->hbalock);
+
+   /* Reestablish the local initiator port.
+* The offline process destroyed the previous lport.
+*/
+   if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) {
+   if (!phba->nvmet_support) {
+   error = lpfc_nvme_create_localport(phba->pport);
+   if (error) {
+   lpfc_printf_log(phba, KERN_ERR,
+   LOG_INIT,
+   "6132 NVME restore reg "
+   "failed on nvmei error "
+   "x%x\n", error);
+   }
+   }
+   }
} else {
lpfc_sli_queue_init(phba);
if (lpfc_sli_hba_setup(phba)) { /* Initialize SLI2/SLI3 HBA */
-- 
2.13.1



[PATCH 15/21] lpfc: Fix relative offset error on large nvmet target ios

2017-08-02 Thread James Smart
From: Dick Kennedy 

if the nvmet_fc transport breaks an io into multiple sequences,
the driver will improperly set the relative offset on the 2nd through
N sequences.

Correct by properly formatting the hw cmd so the relative offset is
picked up from the hw cmd.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvmet.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index cd6c93a17760..40fa5dd72bfa 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -559,7 +559,7 @@ lpfc_nvmet_xmt_fcp_op_cmp(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdwqe,
/* lpfc_nvmet_xmt_fcp_release() will recycle the context */
} else {
ctxp->entry_cnt++;
-   start_clean = offsetof(struct lpfc_iocbq, wqe);
+   start_clean = offsetof(struct lpfc_iocbq, iocb_flag);
memset(((char *)cmdwqe) + start_clean, 0,
   (sizeof(struct lpfc_iocbq) - start_clean));
 #ifdef CONFIG_SCSI_LPFC_DEBUG_FS
@@ -1024,7 +1024,6 @@ lpfc_nvmet_setup_io_context(struct lpfc_hba *phba)
/* Word 7 */
bf_set(wqe_ct, &wqe->generic.wqe_com, SLI4_CT_RPI);
bf_set(wqe_class, &wqe->generic.wqe_com, CLASS3);
-   bf_set(wqe_pu, &wqe->generic.wqe_com, 1);
/* Word 10 */
bf_set(wqe_nvme, &wqe->fcp_tsend.wqe_com, 1);
bf_set(wqe_ebde_cnt, &wqe->generic.wqe_com, 0);
@@ -1974,6 +1973,7 @@ lpfc_nvmet_prep_fcp_wqe(struct lpfc_hba *phba,
   nvmewqe->sli4_xritag);
 
/* Word 7 */
+   bf_set(wqe_pu, &wqe->fcp_tsend.wqe_com, 1);
bf_set(wqe_cmnd, &wqe->fcp_tsend.wqe_com, CMD_FCP_TSEND64_WQE);
 
/* Word 8 */
@@ -2082,6 +2082,7 @@ lpfc_nvmet_prep_fcp_wqe(struct lpfc_hba *phba,
   nvmewqe->sli4_xritag);
 
/* Word 7 */
+   bf_set(wqe_pu, &wqe->fcp_treceive.wqe_com, 1);
bf_set(wqe_ar, &wqe->fcp_treceive.wqe_com, 0);
bf_set(wqe_cmnd, &wqe->fcp_treceive.wqe_com,
   CMD_FCP_TRECEIVE64_WQE);
@@ -2165,6 +2166,7 @@ lpfc_nvmet_prep_fcp_wqe(struct lpfc_hba *phba,
   nvmewqe->sli4_xritag);
 
/* Word 7 */
+   bf_set(wqe_pu, &wqe->fcp_trsp.wqe_com, 0);
bf_set(wqe_ag, &wqe->fcp_trsp.wqe_com, 1);
bf_set(wqe_cmnd, &wqe->fcp_trsp.wqe_com, CMD_FCP_TRSP64_WQE);
 
-- 
2.13.1



[PATCH 13/21] lpfc: Limit amount of work processed in IRQ

2017-08-02 Thread James Smart
From: Dick Kennedy 

Various oops being seen on being in the ISR too long and cpu
lockups, when under heavy load.

The amount of work being posted off of completion queues kept
the ISR running almost all the time

Correct the issue by limiting the amount of work per itteration.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_sli.c  | 31 +++
 drivers/scsi/lpfc/lpfc_sli4.h |  1 +
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 8476e3d249b0..4a6f432a494e 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -80,8 +80,8 @@ static int lpfc_sli4_fp_handle_cqe(struct lpfc_hba *, struct 
lpfc_queue *,
struct lpfc_cqe *);
 static int lpfc_sli4_post_sgl_list(struct lpfc_hba *, struct list_head *,
   int);
-static void lpfc_sli4_hba_handle_eqe(struct lpfc_hba *, struct lpfc_eqe *,
-   uint32_t);
+static int lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba,
+   struct lpfc_eqe *eqe, uint32_t qidx);
 static bool lpfc_sli4_mbox_completions_pending(struct lpfc_hba *phba);
 static bool lpfc_sli4_process_missed_mbox_completions(struct lpfc_hba *phba);
 static int lpfc_sli4_abort_nvme_io(struct lpfc_hba *phba,
@@ -13010,7 +13010,7 @@ lpfc_sli4_sp_handle_cqe(struct lpfc_hba *phba, struct 
lpfc_queue *cq,
  * completion queue, and then return.
  *
  **/
-static void
+static int
 lpfc_sli4_sp_handle_eqe(struct lpfc_hba *phba, struct lpfc_eqe *eqe,
struct lpfc_queue *speq)
 {
@@ -13034,7 +13034,7 @@ lpfc_sli4_sp_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
lpfc_printf_log(phba, KERN_ERR, LOG_SLI,
"0365 Slow-path CQ identifier "
"(%d) does not exist\n", cqid);
-   return;
+   return 0;
}
 
/* Save EQ associated with this CQ */
@@ -13071,7 +13071,7 @@ lpfc_sli4_sp_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
lpfc_printf_log(phba, KERN_ERR, LOG_SLI,
"0370 Invalid completion queue type (%d)\n",
cq->type);
-   return;
+   return 0;
}
 
/* Catch the no cq entry condition, log an error */
@@ -13086,6 +13086,8 @@ lpfc_sli4_sp_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
/* wake up worker thread if there are works to be done */
if (workposted)
lpfc_worker_wake_up(phba);
+
+   return ecount;
 }
 
 /**
@@ -13393,7 +13395,7 @@ lpfc_sli4_fp_handle_cqe(struct lpfc_hba *phba, struct 
lpfc_queue *cq,
  * queue and process all the entries on the completion queue, rearm the
  * completion queue, and then return.
  **/
-static void
+static int
 lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba, struct lpfc_eqe *eqe,
uint32_t qidx)
 {
@@ -13409,7 +13411,7 @@ lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
"event: majorcode=x%x, minorcode=x%x\n",
bf_get_le32(lpfc_eqe_major_code, eqe),
bf_get_le32(lpfc_eqe_minor_code, eqe));
-   return;
+   return 0;
}
 
/* Get the reference to the corresponding CQ */
@@ -13446,8 +13448,9 @@ lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
 
/* Otherwise this is a Slow path event */
if (cq == NULL) {
-   lpfc_sli4_sp_handle_eqe(phba, eqe, phba->sli4_hba.hba_eq[qidx]);
-   return;
+   ecount = lpfc_sli4_sp_handle_eqe(phba, eqe,
+phba->sli4_hba.hba_eq[qidx]);
+   return ecount;
}
 
 process_cq:
@@ -13456,7 +13459,7 @@ lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
"0368 Miss-matched fast-path completion "
"queue identifier: eqcqid=%d, fcpcqid=%d\n",
cqid, cq->queue_id);
-   return;
+   return 0;
}
 
/* Save EQ associated with this CQ */
@@ -13486,6 +13489,8 @@ lpfc_sli4_hba_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe,
/* wake up worker thread if there are works to be done */
if (workposted)
lpfc_worker_wake_up(phba);
+
+   return ecount;
 }
 
 static void
@@ -13709,6 +13714,7 @@ lpfc_sli4_hba_intr_handler(int irq, void *dev_id)
struct lpfc_eqe *eqe;
unsigned long iflag;
int ecount = 0;
+   int ccount = 0;
int hba_eqidx;
 
/* Get the driver's phba structure from the dev_id */
@@ -13760,8 +13766,9 @@ lpfc_sli4_hba_intr_handler(

[PATCH 08/21] lpfc: Fix handling of FCP and NVME FC4 types in Pt2Pt topology

2017-08-02 Thread James Smart
From: Dick Kennedy 

After link bounce in a NVME Pt2Pt config, the driver managed to
map the same nport twice, resulting in multiple device nodes for the
same namespace.

In Pt2Pt, the driver must send PRLI's for both (scsi) FCP and NVME
rather than using fabric aids. The driver was inconsistent on handling
various PRLI completions, especially rejects, which had reject codes
cross the different protocol PRLI completions.

Fixed to perform the following:
if nvmet mode (fc port can only be a nvme target) - rejects all
unsolicitly FCP PRLI's. Never issues a FCP PRLI.

The multiple protocol PRLI's are sent simultaneously. However, driver
will now only state transition after both PRLI's are complete. New
flags were added to aid tracking the responses from the different PRLI's.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_disc.h  |  1 +
 drivers/scsi/lpfc/lpfc_els.c   | 30 ++
 drivers/scsi/lpfc/lpfc_nportdisc.c |  9 +
 3 files changed, 40 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_disc.h b/drivers/scsi/lpfc/lpfc_disc.h
index 094c97b9e5f7..f9a566eaef04 100644
--- a/drivers/scsi/lpfc/lpfc_disc.h
+++ b/drivers/scsi/lpfc/lpfc_disc.h
@@ -159,6 +159,7 @@ struct lpfc_node_rrq {
 #define NLP_RNID_SND   0x0400  /* sent RNID request for this entry */
 #define NLP_ELS_SND_MASK   0x07e0  /* sent ELS request for this entry */
 #define NLP_NVMET_RECOV0x1000   /* NVMET auditing node for recovery. */
+#define NLP_FCP_PRLI_RJT   0x2000   /* Rport does not support FCP PRLI. */
 #define NLP_DEFER_RM   0x0001  /* Remove this ndlp if no longer used */
 #define NLP_DELAY_TMO  0x0002  /* delay timeout is running for node */
 #define NLP_NPR_2B_DISC0x0004  /* node is included in num_disc_nodes */
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 9e9aa8bb7001..6962e22087c8 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -1966,6 +1966,7 @@ int
 lpfc_issue_els_plogi(struct lpfc_vport *vport, uint32_t did, uint8_t retry)
 {
struct lpfc_hba  *phba = vport->phba;
+   struct Scsi_Host *shost;
struct serv_parm *sp;
struct lpfc_nodelist *ndlp;
struct lpfc_iocbq *elsiocb;
@@ -1984,6 +1985,11 @@ lpfc_issue_els_plogi(struct lpfc_vport *vport, uint32_t 
did, uint8_t retry)
if (!elsiocb)
return 1;
 
+   shost = lpfc_shost_from_vport(vport);
+   spin_lock_irq(shost->host_lock);
+   ndlp->nlp_flag &= ~NLP_FCP_PRLI_RJT;
+   spin_unlock_irq(shost->host_lock);
+
pcmd = (uint8_t *) (((struct lpfc_dmabuf *) elsiocb->context2)->virt);
 
/* For PLOGI request, remainder of payload is service parameters */
@@ -3442,6 +3448,23 @@ lpfc_els_retry(struct lpfc_hba *phba, struct lpfc_iocbq 
*cmdiocb,
goto out_retry;
}
break;
+   case LSRJT_CMD_UNSUPPORTED:
+   /* lpfc nvmet returns this type of LS_RJT when it
+* receives an FCP PRLI because lpfc nvmet only
+* support NVME.  ELS request is terminated for FCP4
+* on this rport.
+*/
+   if (stat.un.b.lsRjtRsnCodeExp ==
+   LSEXP_REQ_UNSUPPORTED) {
+   if (cmd == ELS_CMD_PRLI) {
+   spin_lock_irq(shost->host_lock);
+   ndlp->nlp_flag |= NLP_FCP_PRLI_RJT;
+   spin_unlock_irq(shost->host_lock);
+   retry = 0;
+   goto out_retry;
+   }
+   }
+   break;
}
break;
 
@@ -8013,6 +8036,13 @@ lpfc_els_unsol_buffer(struct lpfc_hba *phba, struct 
lpfc_sli_ring *pring,
rjt_exp = LSEXP_NOTHING_MORE;
break;
}
+
+   /* NVMET accepts NVME PRLI only.  Reject FCP PRLI */
+   if (cmd == ELS_CMD_PRLI && phba->nvmet_support) {
+   rjt_err = LSRJT_CMD_UNSUPPORTED;
+   rjt_exp = LSEXP_REQ_UNSUPPORTED;
+   break;
+   }
lpfc_disc_state_machine(vport, ndlp, elsiocb, NLP_EVT_RCV_PRLI);
break;
case ELS_CMD_LIRR:
diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c 
b/drivers/scsi/lpfc/lpfc_nportdisc.c
index a4488d6339c1..f3ad7cac355d 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1895,6 +1895,15 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vport *vport, 
struct lpfc_nodelist *ndlp,
goto out;
}
 
+   /* When the rport rejected t

[PATCH 21/21] lpfc: lpfc version bump 11.4.0.3

2017-08-02 Thread James Smart
From: Dick Kennedy 

Update driver version to 11.4.0.3

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
index c6a24c3e2d5e..6aa192b3e4bf 100644
--- a/drivers/scsi/lpfc/lpfc_version.h
+++ b/drivers/scsi/lpfc/lpfc_version.h
@@ -20,7 +20,7 @@
  * included with this package. *
  ***/
 
-#define LPFC_DRIVER_VERSION "11.4.0.1"
+#define LPFC_DRIVER_VERSION "11.4.0.3"
 #define LPFC_DRIVER_NAME   "lpfc"
 
 /* Used for SLI 2/3 */
-- 
2.13.1



[PATCH 10/21] lpfc: Fix crash in lpfc nvmet when fc port is reset

2017-08-02 Thread James Smart
From: Dick Kennedy 

in adapter reset tests, an oops was seen with a NULL pointer in
lpfc_free_rq_buffer+0x20/0x60

The driver is failing to properly repost the nvmet sgl list when
recovering from the reset. Thus the driver eventually trys to
walk an errant buffer list.

Corrected the sgl buffer recovery as well as strengthening the
initialization of the bufferlist.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_init.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 491aa95eb0f6..5f32a7fe169d 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3226,6 +3226,13 @@ lpfc_offline(struct lpfc_hba *phba)
 
/* stop port and all timers associated with this hba */
lpfc_stop_port(phba);
+
+   /* Tear down the local and target port registrations.  The
+* nvme transports need to cleanup.
+*/
+   lpfc_nvmet_destroy_targetport(phba);
+   lpfc_nvme_destroy_localport(phba->pport);
+
vports = lpfc_create_vport_work_array(phba);
if (vports != NULL)
for (i = 0; i <= phba->max_vports && vports[i] != NULL; i++)
@@ -6516,6 +6523,12 @@ lpfc_free_nvmet_sgl_list(struct lpfc_hba *phba)
lpfc_nvmet_buf_free(phba, sglq_entry->virt, sglq_entry->phys);
kfree(sglq_entry);
}
+
+   /* Update the nvmet_xri_cnt to reflect no current sgls.
+* The next initialization cycle sets the count and allocates
+* the sgls over again.
+*/
+   phba->sli4_hba.nvmet_xri_cnt = 0;
 }
 
 /**
@@ -8301,6 +8314,9 @@ lpfc_sli4_queue_create(struct lpfc_hba *phba)
goto out_error;
}
 
+   /* Put list in known state in case driver load fails. */
+   INIT_LIST_HEAD(&qdesc->rqbp->rqb_buffer_list);
+
/* Create NVMET Receive Queue for data */
qdesc = lpfc_sli4_queue_alloc(phba,
  phba->sli4_hba.rq_esize,
-- 
2.13.1



[PATCH 06/21] lpfc: convert info messages to standard messages

2017-08-02 Thread James Smart
From: Dick Kennedy 

Transitioned some informational discovery messages to now always
be displayed when log_verbose is set.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_ct.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 9c0c1463057d..33417681f5d4 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -955,7 +955,7 @@ lpfc_cmpl_ct_cmd_gft_id(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
CTrsp = (struct lpfc_sli_ct_request *)outp->virt;
fc4_data_0 = be32_to_cpu(CTrsp->un.gft_acc.fc4_types[0]);
fc4_data_1 = be32_to_cpu(CTrsp->un.gft_acc.fc4_types[1]);
-   lpfc_printf_vlog(vport, KERN_ERR, LOG_DISCOVERY,
+   lpfc_printf_vlog(vport, KERN_INFO, LOG_DISCOVERY,
 "3062 DID x%06x GFT Wd0 x%08x Wd1 x%08x\n",
 did, fc4_data_0, fc4_data_1);
 
@@ -969,7 +969,7 @@ lpfc_cmpl_ct_cmd_gft_id(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
ndlp->nlp_fc4_type |= NLP_FC4_FCP;
if (fc4_data_1 &  LPFC_FC4_TYPE_BITMASK)
ndlp->nlp_fc4_type |= NLP_FC4_NVME;
-   lpfc_printf_vlog(vport, KERN_ERR, LOG_DISCOVERY,
+   lpfc_printf_vlog(vport, KERN_INFO, LOG_DISCOVERY,
 "3064 Setting ndlp %p, DID x%06x with "
 "FC4 x%08x, Data: x%08x x%08x\n",
 ndlp, did, ndlp->nlp_fc4_type,
-- 
2.13.1



[PATCH 09/21] lpfc: Fix duplicate NVME rport entries and namespaces.

2017-08-02 Thread James Smart
From: Dick Kennedy 

After lip, the driver sometimes would have two rports for the same
device, allowing the namespaces to be duplicated by nvme.

In lpfc_plogi_confirm_nport() the driver was not swapping the
nrport maintained by the ndlp's undergoing address swapping. This
allowed the 2nd rport to sneak in as it was considered a separate
device.

This patch adds the fixes to Swap the nrport in each ndlp and take
care of the reference counts on the ndlps similar to FCP rports.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_els.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 6962e22087c8..fe0dd42b75af 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -1527,6 +1527,7 @@ lpfc_plogi_confirm_nport(struct lpfc_hba *phba, uint32_t 
*prsp,
uint8_t  name[sizeof(struct lpfc_name)];
uint32_t rc, keepDID = 0, keep_nlp_flag = 0;
uint16_t keep_nlp_state;
+   struct lpfc_nvme_rport *keep_nrport = NULL;
int  put_node;
int  put_rport;
unsigned long *active_rrqs_xri_bitmap = NULL;
@@ -1624,6 +1625,10 @@ lpfc_plogi_confirm_nport(struct lpfc_hba *phba, uint32_t 
*prsp,
keep_nlp_state = new_ndlp->nlp_state;
lpfc_nlp_set_state(vport, new_ndlp, ndlp->nlp_state);
 
+   /* For nvme, swap the nrport. */
+   keep_nrport = new_ndlp->nrport;
+   new_ndlp->nrport = ndlp->nrport;
+
/* Move this back to NPR state */
if (memcmp(&ndlp->nlp_portname, name, sizeof(struct lpfc_name)) == 0) {
/* The new_ndlp is replacing ndlp totally, so we need
@@ -1646,6 +1651,13 @@ lpfc_plogi_confirm_nport(struct lpfc_hba *phba, uint32_t 
*prsp,
}
new_ndlp->nlp_type = ndlp->nlp_type;
}
+
+   /* Fix up the nvme rport */
+   if (ndlp->nrport) {
+   ndlp->nrport = NULL;
+   lpfc_nlp_put(ndlp);
+   }
+
/* We shall actually free the ndlp with both nlp_DID and
 * nlp_portname fields equals 0 to avoid any ndlp on the
 * nodelist never to be used.
@@ -1690,6 +1702,14 @@ lpfc_plogi_confirm_nport(struct lpfc_hba *phba, uint32_t 
*prsp,
keep_nlp_state = NLP_STE_NPR_NODE;
lpfc_nlp_set_state(vport, ndlp, keep_nlp_state);
 
+   /* Previous ndlp no longer active with nvme host transport.
+* Remove reference from earlier registration unless the
+* nvme host took care of it.
+*/
+   if (ndlp->nrport)
+   lpfc_nlp_put(ndlp);
+   ndlp->nrport = keep_nrport;
+
/* Fix up the rport accordingly */
rport = ndlp->rport;
if (rport) {
-- 
2.13.1



[PATCH 18/21] lpfc: remove console log clutter

2017-08-02 Thread James Smart
Change hw queue binding messages to info - not error.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 8e7cdbd5d7d3..d3c171a72ae0 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -110,7 +110,7 @@ lpfc_nvme_create_queue(struct nvme_fc_local_port 
*pnvme_lport,
qhandle->index = qidx;
}
 
-   lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME,
+   lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
 "6073 Binding %s HdwQueue %d  (cpu %d) to "
 "io_channel %d qhandle %p\n", str,
 qidx, qhandle->cpu_id, qhandle->index, qhandle);
-- 
2.13.1



[PATCH 04/21] lpfc: Fix rediscovery on switch blade pull

2017-08-02 Thread James Smart
From: Dick Kennedy 

When the switch blade is pulled out then plugged back in, the driver
does not issue a PLOGI to the target

When the switch blade is pulled out, it does not reset the link. The
driver ends up issuing a LOGO to the target, and finally sees devloss.
Since the driver believes that a LOGO is outstanding, it does not
issue a PLOGI to the target upon link up

Correct by placing the ndlp in UNUSED state When devloss happens in
LOGO_ISSUE state.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nportdisc.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c 
b/drivers/scsi/lpfc/lpfc_nportdisc.c
index 95b2b43ac37d..a4488d6339c1 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -2192,12 +2192,15 @@ lpfc_device_rm_logo_issue(struct lpfc_vport *vport, 
struct lpfc_nodelist *ndlp,
  void *arg, uint32_t evt)
 {
/*
-* Take no action.  If a LOGO is outstanding, then possibly DevLoss has
-* timed out and is calling for Device Remove.  In this case, the LOGO
-* must be allowed to complete in state LOGO_ISSUE so that the rpi
-* and other NLP flags are correctly cleaned up.
+* DevLoss has timed out and is calling for Device Remove.
+* In this case, abort the LOGO and cleanup the ndlp
 */
-   return ndlp->nlp_state;
+
+   lpfc_unreg_rpi(vport, ndlp);
+   /* software abort outstanding PLOGI */
+   lpfc_els_abort(vport->phba, ndlp);
+   lpfc_drop_node(vport, ndlp);
+   return NLP_STE_FREED_NODE;
 }
 
 static uint32_t
-- 
2.13.1



[PATCH 00/21] lpfc updates for 11.4.0.3

2017-08-02 Thread James Smart
This patch set provides a number of bug fixes and two additions.
The additions are BB credit support and Adapter type 6 support.

The patches were cut against the Martin's 4.13/scsi-fixes tree.
There are no outside dependencies.

Dick Kennedy (18):
  lpfc: Fix opps when ExpressLane is enabled
  lpfc: Fix plogi collision that causes illegal state transition
  lpfc: Fix loop mode target discovery
  lpfc: Fix rediscovery on switch blade pull
  lpfc: Fix oops when NVME Target is discovered in a nonNVME environment
  lpfc: convert info messages to standard messages
  lpfc: Correct return error codes to align with nvme_fc transport
  lpfc: Fix handling of FCP and NVME FC4 types in Pt2Pt topology
  lpfc: Fix duplicate NVME rport entries and namespaces.
  lpfc: Fix crash in lpfc nvmet when fc port is reset
  lpfc: Fix NVME PRLI handling during RSCN
  lpfc: Correct issues with FAWWN and FDISCs
  lpfc: Limit amount of work processed in IRQ
  lpfc: Fix MRQ > 1 context list handling
  lpfc: Fix relative offset error on large nvmet target ios
  lpfc: Fix nvme target failure after 2nd adapter reset
  lpfc: Fix bad sgl reposting after 2nd adapter reset
  lpfc: lpfc version bump 11.4.0.3

James Smart (3):
  lpfc: remove console log clutter
  lpfc: Add Buffer to Buffer credit recovery support
  lpfc: Add new adapter type 6 support

 drivers/scsi/lpfc/lpfc.h   |   3 +-
 drivers/scsi/lpfc/lpfc_attr.c  |  52 -
 drivers/scsi/lpfc/lpfc_attr.h  |  10 +
 drivers/scsi/lpfc/lpfc_crtn.h  |   5 +-
 drivers/scsi/lpfc/lpfc_ct.c|   4 +-
 drivers/scsi/lpfc/lpfc_debugfs.c   |  31 +--
 drivers/scsi/lpfc/lpfc_debugfs.h   |  11 +-
 drivers/scsi/lpfc/lpfc_disc.h  |   1 +
 drivers/scsi/lpfc/lpfc_els.c   | 101 +++-
 drivers/scsi/lpfc/lpfc_hbadisc.c   |  12 +-
 drivers/scsi/lpfc/lpfc_hw.h|  18 +-
 drivers/scsi/lpfc/lpfc_hw4.h   | 108 -
 drivers/scsi/lpfc/lpfc_init.c  | 209 ++---
 drivers/scsi/lpfc/lpfc_mbox.c  |  35 ++-
 drivers/scsi/lpfc/lpfc_nportdisc.c |  25 +-
 drivers/scsi/lpfc/lpfc_nvme.c  |  29 ++-
 drivers/scsi/lpfc/lpfc_nvmet.c | 276 --
 drivers/scsi/lpfc/lpfc_nvmet.h |  14 ++
 drivers/scsi/lpfc/lpfc_sli.c   | 461 +
 drivers/scsi/lpfc/lpfc_sli4.h  |  50 +++-
 drivers/scsi/lpfc/lpfc_version.h   |   2 +-
 21 files changed, 1142 insertions(+), 315 deletions(-)

-- 
2.13.1



[PATCH 17/21] lpfc: Fix bad sgl reposting after 2nd adapter reset

2017-08-02 Thread James Smart
From: Dick Kennedy 

Fix bad sgl reposting after 2nd adapter reset

port issue was fixed, the hbacmd reset would take
more than 8 minutes to complete.

There were conflicting NVME SGL posting/reposting responsibilities
between lpfc_online()/lpfc_sli4_hba_setup() and
lpfc_nvme_create_localport().  The lpfc_online() causes a REPOST
on existing NVME SGLs which is not released during the fc port reset.
However, lpfc_nvme_create_localport() wants to allocate new NVME
buffers and post them. Both cancelled out each other which had a side
effect of hosing the mailbox handling that was used to remove the sgl
lists - causing multiple 60s mbx timeouts.

Fix by preserving all SGL lists over the fc port reset.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvme.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 87e0743c4ace..8e7cdbd5d7d3 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2181,8 +2181,15 @@ lpfc_nvme_create_localport(struct lpfc_vport *vport)
vport->localport = localport;
lport->vport = vport;
vport->nvmei_support = 1;
-   len  = lpfc_new_nvme_buf(vport, phba->sli4_hba.nvme_xri_max);
-   vport->phba->total_nvme_bufs += len;
+
+   /* Don't post more new bufs if repost already recovered
+* the nvme sgls.
+*/
+   if (phba->sli4_hba.nvme_xri_cnt == 0) {
+   len  = lpfc_new_nvme_buf(vport,
+phba->sli4_hba.nvme_xri_max);
+   vport->phba->total_nvme_bufs += len;
+   }
}
 
return ret;
-- 
2.13.1



[PATCH 19/21] lpfc: Add Buffer to Buffer credit recovery support

2017-08-02 Thread James Smart
Add Buffer to buffer credit recovery support to the driver.
This is a negotiated feature with the peer that allows for both
sides to detect dropped RRDY's and FC Frames and recover credit.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc.h |  3 ++-
 drivers/scsi/lpfc/lpfc_attr.c| 41 
 drivers/scsi/lpfc/lpfc_attr.h| 10 ++
 drivers/scsi/lpfc/lpfc_els.c | 14 +-
 drivers/scsi/lpfc/lpfc_hbadisc.c | 12 ++--
 drivers/scsi/lpfc/lpfc_hw.h  | 18 +++---
 drivers/scsi/lpfc/lpfc_hw4.h | 23 ++
 drivers/scsi/lpfc/lpfc_init.c|  5 +
 drivers/scsi/lpfc/lpfc_mbox.c| 35 +++---
 drivers/scsi/lpfc/lpfc_sli4.h| 15 +++
 10 files changed, 162 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 562dc0139735..50aaae3d966e 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -733,7 +733,6 @@ struct lpfc_hba {
uint32_t fc_rttov;  /* R_T_TOV timer value */
uint32_t fc_altov;  /* AL_TOV timer value */
uint32_t fc_crtov;  /* C_R_TOV timer value */
-   uint32_t fc_citov;  /* C_I_TOV timer value */
 
struct serv_parm fc_fabparam;   /* fabric service parameters buffer */
uint8_t alpa_map[128];  /* AL_PA map from READ_LA */
@@ -757,6 +756,7 @@ struct lpfc_hba {
 #define LPFC_NVMET_MAX_PORTS   32
uint8_t  mds_diags_support;
uint32_t initial_imax;
+   uint8_t  bbcredit_support;
 
/* HBA Config Parameters */
uint32_t cfg_ack0;
@@ -836,6 +836,7 @@ struct lpfc_hba {
uint32_t cfg_enable_SmartSAN;
uint32_t cfg_enable_mds_diags;
uint32_t cfg_enable_fc4_type;
+   uint32_t cfg_enable_bbcr;   /*Enable BB Credit Recovery*/
uint32_t cfg_xri_split;
 #define LPFC_ENABLE_FCP  1
 #define LPFC_ENABLE_NVME 2
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index d3d01ff44423..0806323829e6 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -1889,6 +1889,36 @@ static inline bool lpfc_rangecheck(uint val, uint min, 
uint max)
 }
 
 /**
+ * lpfc_enable_bbcr_set: Sets an attribute value.
+ * @phba: pointer the the adapter structure.
+ * @val: integer attribute value.
+ *
+ * Description:
+ * Validates the min and max values then sets the
+ * adapter config field if in the valid range. prints error message
+ * and does not set the parameter if invalid.
+ *
+ * Returns:
+ * zero on success
+ * -EINVAL if val is invalid
+ */
+static ssize_t
+lpfc_enable_bbcr_set(struct lpfc_hba *phba, uint val)
+{
+   if (lpfc_rangecheck(val, 0, 1) && phba->sli_rev == LPFC_SLI_REV4) {
+   lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
+   "3068 %s_enable_bbcr changed from %d to %d\n",
+   LPFC_DRIVER_NAME, phba->cfg_enable_bbcr, val);
+   phba->cfg_enable_bbcr = val;
+   return 0;
+   }
+   lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
+   "0451 %s_enable_bbcr cannot set to %d, range is 0, 1\n",
+   LPFC_DRIVER_NAME, val);
+   return -EINVAL;
+}
+
+/**
  * lpfc_param_show - Return a cfg attribute value in decimal
  *
  * Description:
@@ -5111,6 +5141,14 @@ LPFC_ATTR_R(sg_seg_cnt, LPFC_DEFAULT_SG_SEG_CNT, 
LPFC_DEFAULT_SG_SEG_CNT,
  */
 LPFC_ATTR_R(enable_mds_diags, 0, 0, 1, "Enable MDS Diagnostics");
 
+/*
+ * lpfc_enable_bbcr: Enable BB Credit Recovery
+ *   0  = BB Credit Recovery disabled
+ *   1  = BB Credit Recovery enabled (default)
+ * Value range is [0,1]. Default value is 1.
+ */
+LPFC_BBCR_ATTR_RW(enable_bbcr, 1, 0, 1, "Enable BBC Recovery");
+
 struct device_attribute *lpfc_hba_attrs[] = {
&dev_attr_nvme_info,
&dev_attr_bg_info,
@@ -5218,6 +5256,7 @@ struct device_attribute *lpfc_hba_attrs[] = {
&dev_attr_protocol,
&dev_attr_lpfc_xlane_supported,
&dev_attr_lpfc_enable_mds_diags,
+   &dev_attr_lpfc_enable_bbcr,
NULL,
 };
 
@@ -6229,11 +6268,13 @@ lpfc_get_cfgparam(struct lpfc_hba *phba)
lpfc_nvmet_fb_size_init(phba, lpfc_nvmet_fb_size);
lpfc_fcp_io_channel_init(phba, lpfc_fcp_io_channel);
lpfc_nvme_io_channel_init(phba, lpfc_nvme_io_channel);
+   lpfc_enable_bbcr_init(phba, lpfc_enable_bbcr);
 
if (phba->sli_rev != LPFC_SLI_REV4) {
/* NVME only supported on SLI4 */
phba->nvmet_support = 0;
phba->cfg_enable_fc4_type = LPFC_ENABLE_FCP;
+   phba->cfg_enable_bbcr = 0;
} else {
/* We MUST have FCP support */
if (!(phba->cfg_enable_fc4_type & LPFC_ENABLE_FCP))
diff --git a/drivers/scsi/lpfc/lpfc_attr.h b/drivers/scsi/lpfc/lpfc_attr.h
index d56dafcdd563..931db52692f5 100644
--- 

[PATCH 01/21] lpfc: Fix opps when ExpressLane is enabled

2017-08-02 Thread James Smart
From: Dick Kennedy 

Null pointer dereference in lpfc_sli4_fof_intr_handler

The driver does not set up cq->assoc_qp for sli4_hba->oas_cq

Initialize cq->assoc_qp before accessing it

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_sli.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index e948ea05fd33..0615bf9def23 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -13557,6 +13557,9 @@ lpfc_sli4_fof_handle_eqe(struct lpfc_hba *phba, struct 
lpfc_eqe *eqe)
/* Save EQ associated with this CQ */
cq->assoc_qp = phba->sli4_hba.fof_eq;
 
+   /* Save EQ associated with this CQ */
+   cq->assoc_qp = phba->sli4_hba.fof_eq;
+
/* Process all the entries to the OAS CQ */
while ((cqe = lpfc_sli4_cq_get(cq))) {
workposted |= lpfc_sli4_fp_handle_cqe(phba, cq, cqe);
-- 
2.13.1



[PATCH 05/21] lpfc: Fix oops when NVME Target is discovered in a nonNVME environment

2017-08-02 Thread James Smart
From: Dick Kennedy 

lpfc oops when it discovers a NVME target but is configured for SCSI
only operation. Oops is in lpfc_nvme_register_port+0x33/0x300.

The localport is not valid so it should not have been referenced.

Added validity check for localport

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_nvme.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 0a0a1b92d01d..2f50df6a3dca 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2296,6 +2296,9 @@ lpfc_nvme_register_port(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp)
 ndlp->nlp_DID, ndlp->nlp_type);
 
localport = vport->localport;
+   if (!localport)
+   return 0;
+
lport = (struct lpfc_nvme_lport *)localport->private;
 
/* NVME rports are not preserved across devloss.
-- 
2.13.1



[PATCH 1/3] scsi: mptfusion: constify pci_device_id.

2017-08-02 Thread Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/message/fusion/mptspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index 9a336a1..f9823bb 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1243,7 +1243,7 @@ static struct spi_function_template 
mptspi_transport_functions = {
  * Supported hardware
  */
 
-static struct pci_device_id mptspi_pci_table[] = {
+static const struct pci_device_id mptspi_pci_table[] = {
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_53C1030,
PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_ATTO, MPI_MANUFACTPAGE_DEVID_53C1030,
-- 
2.7.4



[PATCH 3/3] scsi: mptsas: constify pci_device_id.

2017-08-02 Thread Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/message/fusion/mptsas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index f6308ad..8604573 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -5358,7 +5358,7 @@ static void mptsas_remove(struct pci_dev *pdev)
mptscsih_remove(pdev);
 }
 
-static struct pci_device_id mptsas_pci_table[] = {
+static const struct pci_device_id mptsas_pci_table[] = {
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1064,
PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_SAS1068,
-- 
2.7.4



[PATCH 2/3] scsi: mptfc: constify pci_device_id.

2017-08-02 Thread Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/message/fusion/mptfc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptfc.c b/drivers/message/fusion/mptfc.c
index d065062..82cb864 100644
--- a/drivers/message/fusion/mptfc.c
+++ b/drivers/message/fusion/mptfc.c
@@ -138,7 +138,7 @@ static struct scsi_host_template mptfc_driver_template = {
  * Supported hardware
  */
 
-static struct pci_device_id mptfc_pci_table[] = {
+static const struct pci_device_id mptfc_pci_table[] = {
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVICEID_FC909,
PCI_ANY_ID, PCI_ANY_ID },
{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVICEID_FC919,
-- 
2.7.4



[PATCH 0/3] constify scsi pci_device_id.

2017-08-02 Thread Arvind Yadav
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by  work with
const pci_device_id. So mark the non-const structs as const.

Arvind Yadav (3):
  [PATCH 1/3] scsi: mptfusion: constify pci_device_id.
  [PATCH 2/3] scsi: mptfc: constify pci_device_id.
  [PATCH 3/3] scsi: mptsas: constify pci_device_id.

 drivers/message/fusion/mptfc.c  | 2 +-
 drivers/message/fusion/mptsas.c | 2 +-
 drivers/message/fusion/mptspi.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.4



Re: [PATCH 03/14] blk-mq: introduce blk_mq_dispatch_rq_from_ctxs()

2017-08-02 Thread kbuild test robot
Hi Ming,

[auto build test ERROR on block/for-next]
[also build test ERROR on v4.13-rc3 next-20170802]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ming-Lei/blk-mq-sched-fix-SCSI-MQ-performance-regression/20170801-031007
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
for-next
config: x86_64-randconfig-b0-08022356 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   block/blk-mq.c: In function 'blk_mq_flush_busy_ctxs':
>> block/blk-mq.c:861: error: unknown field 'list' specified in initializer
>> block/blk-mq.c:861: warning: missing braces around initializer
   block/blk-mq.c:861: warning: (near initialization for 'data.')
   block/blk-mq.c: In function 'blk_mq_dispatch_rq_from_ctxs':
>> block/blk-mq.c:872: error: unknown field 'rq' specified in initializer
   block/blk-mq.c:872: warning: missing braces around initializer
   block/blk-mq.c:872: warning: (near initialization for 'data.')

vim +/list +861 block/blk-mq.c

22e09fd59 Ming Lei  2017-08-01  852  
320ae51fe Jens Axboe2013-10-24  853  /*
1429d7c94 Jens Axboe2014-05-19  854   * Process software queues that have 
been marked busy, splicing them
1429d7c94 Jens Axboe2014-05-19  855   * to the for-dispatch
1429d7c94 Jens Axboe2014-05-19  856   */
2c3ad6679 Jens Axboe2016-12-14  857  void blk_mq_flush_busy_ctxs(struct 
blk_mq_hw_ctx *hctx, struct list_head *list)
1429d7c94 Jens Axboe2014-05-19  858  {
4b5ef3bbb Ming Lei  2017-08-01  859 struct ctx_iter_data data = {
88459642c Omar Sandoval 2016-09-17  860 .hctx = hctx,
88459642c Omar Sandoval 2016-09-17 @861 .list = list,
88459642c Omar Sandoval 2016-09-17  862 };
1429d7c94 Jens Axboe2014-05-19  863  
88459642c Omar Sandoval 2016-09-17  864 
sbitmap_for_each_set(&hctx->ctx_map, flush_busy_ctx, &data);
1429d7c94 Jens Axboe2014-05-19  865  }
2c3ad6679 Jens Axboe2016-12-14  866  
EXPORT_SYMBOL_GPL(blk_mq_flush_busy_ctxs);
1429d7c94 Jens Axboe2014-05-19  867  
22e09fd59 Ming Lei  2017-08-01  868  struct request 
*blk_mq_dispatch_rq_from_ctxs(struct blk_mq_hw_ctx *hctx)
22e09fd59 Ming Lei  2017-08-01  869  {
22e09fd59 Ming Lei  2017-08-01  870 struct ctx_iter_data data = {
22e09fd59 Ming Lei  2017-08-01  871 .hctx = hctx,
22e09fd59 Ming Lei  2017-08-01 @872 .rq   = NULL,
22e09fd59 Ming Lei  2017-08-01  873 };
22e09fd59 Ming Lei  2017-08-01  874  
22e09fd59 Ming Lei  2017-08-01  875 
sbitmap_for_each_set(&hctx->ctx_map, dispatch_rq_from_ctx, &data);
22e09fd59 Ming Lei  2017-08-01  876  
22e09fd59 Ming Lei  2017-08-01  877 return data.rq;
22e09fd59 Ming Lei  2017-08-01  878  }
22e09fd59 Ming Lei  2017-08-01  879  

:: The code at line 861 was first introduced by commit
:: 88459642cba452630326b9cab1c651e09577d4e4 blk-mq: abstract tag allocation 
out into sbitmap library

:: TO: Omar Sandoval 
:: CC: Jens Axboe 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 32/47] scsi: Use scsi_target as argument for eh_target_reset_handler()

2017-08-02 Thread Steffen Maier

just an intermediate update on storage processing of target reset...

On 07/25/2017 04:19 PM, Hannes Reinecke wrote:

On 07/24/2017 08:10 PM, Steffen Maier wrote:

On 06/28/2017 10:32 AM, Hannes Reinecke wrote:

The target reset function should only depend on the scsi target,
not the scsi command.

Signed-off-by: Hannes Reinecke 
---



   drivers/s390/scsi/zfcp_scsi.c   | 20 ++--



   33 files changed, 214 insertions(+), 174 deletions(-)



diff --git a/drivers/s390/scsi/zfcp_scsi.c
b/drivers/s390/scsi/zfcp_scsi.c
index dd7bea0..92a3902 100644
--- a/drivers/s390/scsi/zfcp_scsi.c
+++ b/drivers/s390/scsi/zfcp_scsi.c
@@ -309,9 +309,25 @@ static int
zfcp_scsi_eh_device_reset_handler(struct scsi_cmnd *scpnt)
   return zfcp_task_mgmt_function(scpnt->device, FCP_TMF_LUN_RESET);
   }

-static int zfcp_scsi_eh_target_reset_handler(struct scsi_cmnd *scpnt)
+/*
+ * Note: We need to select a LUN as the storage array doesn't
+ * necessarily supports LUN 0 and might refuse the target reset.
+ */


Do you have any real experience with targets regarding this?

Did you even try this and it failed?
If so, how did it fail?


Hehe.

Actually, it was _you_ (well, not you personally, but the zfcp
maintainer at that time) who insisted on _not_ having to rely on LUN 0,
as that LUN might not be available on non-NPIV setups.
In the same vein he argued that we should be using the WLUN here.


Thanks a lot for letting me know!


It seems other drivers hardcode LUN 0 for target reset [see below].

At least you made a similar loop to search for a suitable "victim"
scsi_device with some other driver changes below, so zfcp is not the
only one.

In fact, this is one of my open questions in my own patch set:
Is the TMF flag in the FCP_CMND IU sufficient or does the transmission
path require a valid FCP_LUN also in the same IU even for a target reset.


Technically, you need an IT nexus for the target reset.
As the SCSI target is somewhat under-represented in the linux SCSI stack
typically it's easier to use a scsi device for this, and derive the IT
nexus from there.
And target reset is a tad tricky anyway; it got deprecated with later
SCSI releases (SPC-3?), so chances is that it doesn't do anything.

(You could do yourself a favour and enquire with your friendly array
vendors if _they_ support target reset; I have a strong feeling that
they don't. In which case you might as well drop it completely, and
target reset doing an IT nexus reset.)


# lsscsi
[0:0:0:1073758277]diskIBM  2107900  .280  /dev/sdc
[0:0:0:1073823813]diskIBM  2107900  .280  /dev/sda
[0:0:0:1073889349]diskIBM  2107900  .280  /dev/sdb

With test code I made the following request run into a timeout:

# dd count=1 of=/dev/null if=/dev/sda iflag=direct


[  633.459218] sd 0:0:0:1073823813: [sda] tag#0 Done: TIMEOUT_ERROR Result: 
hostbyte=DID_OK driverbyte=DRIVER_OK
[  633.459267] sd 0:0:0:1073823813: [sda] tag#0 CDB: Read(10) 28 00 00 00 00 00 
00 00 01 00
[  633.459277] sd 0:0:0:1073823813: [sda] tag#0 abort scheduled
[  633.479364] sd 0:0:0:1073823813: [sda] tag#0 aborting command
[  633.479382] sd 0:0:0:1073823813: [sda] tag#0 cmd abort failed


More test code makes the abort fail (before even attempting it).


[  633.479456] scsi host0: scsi_eh_0: waking up 0/1/1
[  633.479483] scsi host0: scsi_eh_prt_fail_stats: cmds failed: 0, cancel: 1
[  633.479492] scsi host0: Total of 1 commands on 1 devices require eh work
[  633.479502] sd 0:0:0:1073823813: scsi_eh_0: Sending BDR
[  633.479512] sd 0:0:0:1073823813: scsi_eh_0: BDR failed


More test code makes the LUN reset fail (before even attempting it).


[  633.479519] scsi host0: scsi_eh_0: Sending target reset to target 0
[  633.483654] sd 0:0:0:1073823813: [sda] tag#0 scsi_eh_done result: 2
[  633.483729] sd 0:0:0:1073823813: [sda] tag#0 Done: SUCCESS Result: 
hostbyte=DID_OK driverbyte=DRIVER_OK
[  633.483736] sd 0:0:0:1073823813: [sda] tag#0 CDB: Test Unit Ready 00 00 00 
00 00 00
[  633.483741] sd 0:0:0:1073823813: [sda] tag#0 Sense Key : Unit Attention [current] 
[  633.483747] sd 0:0:0:1073823813: [sda] tag#0 Add. Sense: Power on, reset, or bus device reset occurred

[  633.483753] sd 0:0:0:1073823813: [sda] tag#0 scsi_send_eh_cmnd timeleft: 1000
[  633.483758] sd 0:0:0:1073823813: [sda] tag#0 scsi_send_eh_cmnd: 
scsi_eh_completed_normally 2001
[  633.483764] sd 0:0:0:1073823813: [sda] tag#0 scsi_eh_tur return: 2001
[  633.484074] sd 0:0:0:1073823813: [sda] tag#0 scsi_eh_done result: 0
[  633.484093] sd 0:0:0:1073823813: [sda] tag#0 scsi_send_eh_cmnd timeleft: 1000
[  633.484118] sd 0:0:0:1073823813: [sda] tag#0 scsi_send_eh_cmnd: 
scsi_eh_completed_normally 2002
[  633.484124] sd 0:0:0:1073823813: [sda] tag#0 scsi_eh_tur return: 2002
[  633.484130] sd 0:0:0:1073823813: [sda] tag#0 scsi_eh_0: flush retry cmd
[  633.484260] scsi host0: waking up host to restart
[  633.484299] scsi host0: scsi_eh_0: sleeping


The target reset succeeds and scsi_

Re: [PATCH] hpsa: add support for legacy boards

2017-08-02 Thread Hannes Reinecke
On 07/11/2017 04:25 PM, Meelis Roos wrote:
>> Add support for legacy boards, ensuring to enable the driver for
>> those boards only when 'hpsa_allow_any' is set.
> 
> Applied this patch, made sure I had compiled in hpsa and not cciss to 
> avoid any variables from initramfs, and still I get this:
> 
> [4.015080] hpsa :00:04.0: unrecognized board ID: 0x40800e11, ignoring.
> [4.098473] hpsa :00:04.0: Board ID not found
> 
> Boot command line was "root=/dev/sda1 console=ttyS0,9600 ro hpsa_allow_any=1" 
> - 
> seems correct.
> 
> By looking at the code, I should see "unsupported board ID:" and it 
> should work, but I see "unrecognized board ID:" and it does not work.
> 
> Hmm, trying hpsa.hpsa_allow_any=1. Much better:
> 
> [3.891531] hpsa :00:04.0: unsupported board ID: 0x40800e11
> [3.962367] hpsa :00:04.0: unsupported board ID: 0x40800e11
> [4.033493] hpsa :00:04.0: Controller reports max supported commands 
> of 0 Using 16 instead. Ensure that firmware is up to date.
> [4.175134] hpsa :00:04.0: Physical aborts not supported
> [4.242931] hpsa :00:04.0: Logical aborts not supported
> [4.309594] hpsa :00:04.0: HP SSD Smart Path aborts not supported
> [4.460889] hpsa :00:04.0: Controller reports max supported commands 
> of 0 Using 16 instead. Ensure that firmware is up to date.
> [4.584679] scsi host0: hpsa
> [4.587842] hpsa :00:04.0: report luns requested format 2, got 0
> [4.613215] hpsa :00:04.0: scsi 0:0:0:0: masked Direct-Access 
> COMPAQ   BD03685A24   PHYS DRV SSDSmartPathCap- En- Exp=0
> [4.613219] hpsa :00:04.0: C0:B1:T0:L0 Volume status is not available 
> through vital product data pages.
> [4.613224] hpsa :00:04.0: scsi 0:1:0:0: offline Direct-Access 
> COMPAQ   LOGICAL VOLUME   RAID-1(+0) SSDSmartPathCap- En- Exp=1
> [4.613229] hpsa :00:04.0: scsi 0:3:0:0: added RAID  
> COMPAQ   Smart Array 5i   controller SSDSmartPathCap- En- Exp=1
> [6.187725] scsi 0:3:0:0: RAID  COMPAQ   Smart Array 5i   2.62 
> PQ: 0 ANSI: 0
> [...]
> [6.726872] VFS: Cannot open root device "sda1" or unknown-block(0,0): 
> error -6
> [6.814364] Please append a correct "root=" boot option; here are the 
> available partitions:
> [6.914403] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(0,0)
> 
> Controller is detected, there is something behind it but no sda is 
> detected and no bootup.
> 
> What next?
> 
As Don indicated, older controller probably don't support volume state
information. But that shouldn't distract us. Will be sending a patch.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


[PATCH] hpsa: disable volume status check for older controller

2017-08-02 Thread Hannes Reinecke
Older Controller might not support volume status, so disable
it if 'hpsa_allow_any' is present.

Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/hpsa.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 2cf6ccc..bd063b8 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3831,6 +3831,17 @@ static int hpsa_update_device_info(struct ctlr_info *h,
if (h->fw_support & MISC_FW_RAID_OFFLOAD_BASIC)
hpsa_get_ioaccel_status(h, scsi3addr, this_device);
volume_offline = hpsa_volume_offline(h, scsi3addr);
+   if (volume_offline == HPSA_VPD_LV_STATUS_UNSUPPORTED &&
+   hpsa_allow_any) {
+   /*
+* Older controllers do not support
+* volume status
+*/
+   dev_info(&h->pdev->dev,
+"C0:T%d:L%d Volume status not available, 
assuming online.\n",
+this_device->target, this_device->lun);
+   volume_offline = 0;
+   }
this_device->volume_offline = volume_offline;
if (volume_offline == HPSA_LV_FAILED) {
rc = HPSA_LV_FAILED;
-- 
1.8.5.6



Re: [PATCH 2/2] lpfc: support nvmet_fc defer_rcv callback

2017-08-02 Thread James Smart

On 8/2/2017 1:32 AM, Johannes Thumshirn wrote:

len += snprintf(buf+len, PAGE_SIZE-len,
-   "FCP: Rcv %08x Release %08x Drop %08x\n",
+   "FCP: Rcv %08x Defer %08x Release %08x "
+   "Drop %08x\n",


Please don't split the string across lines, it makes grepping hard.
Checkpatch actually warns you about that.


The indentation and length of the string exceeds the 80 chararacters. so 
has to be split.  lpfc is littered with this in the debug path. It'll be 
one of the things we address in the efct refactoring. For now, this 
style has been grandfathered in.


-- james


Re: [PATCH 1/2] nvmet_fc: add defer_req callback for deferment of cmd buffer return

2017-08-02 Thread James Smart

On 8/2/2017 1:16 AM, Johannes Thumshirn wrote:

+   for (;;) {
+   deferfcp = list_first_entry_or_null(&queue->pending_cmd_list,
+   struct nvmet_fc_defer_fcp_req, req_list);
+   if (!deferfcp)
+   break;


 while ((deferfcp = list_first_entry_or_null(&queue->pending_cmd_list,
struct nvmet_fc_defer_fcp_req,
req_list)) != NULL) {
?


To me - this is harder to read. But not a big deal.

-- james





[GIT PULL] SCSI fixes for 4.13-rc3

2017-08-02 Thread James Bottomley
This seven is mostly minor build, Kconfig and error leg fixes.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Arnd Bergmann (1):
  scsi: lpfc: fix linking against modular NVMe support

Dan Carpenter (1):
  scsi: qedi: Fix return code in qedi_ep_connect()

Hannes Reinecke (1):
  scsi: scsi_transport_fc: return -EBUSY for deleted vport

Jakub Kicinski (1):
  scsi: aic7xxx: fix firmware build with O=path

Nilesh Javali (1):
  scsi: qedi: Add ISCSI_BOOT_SYSFS to Kconfig

Shu Wang (1):
  scsi: megaraid_sas: fix memleak in megasas_alloc_cmdlist_fusion

Varun Prakash (1):
  scsi: libcxgbi: add check for valid cxgbi_task_data

And the diffstat:

 drivers/scsi/Kconfig|  2 ++
 drivers/scsi/aic7xxx/Makefile   | 12 +++
 drivers/scsi/aic7xxx/aicasm/Makefile| 53 -
 drivers/scsi/cxgbi/libcxgbi.c   |  7 
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  6 +++-
 drivers/scsi/qedi/Kconfig   |  1 +
 drivers/scsi/qedi/qedi_iscsi.c  |  8 ++---
 drivers/scsi/scsi_transport_fc.c|  6 ++--
 8 files changed, 58 insertions(+), 37 deletions(-)

with full diff below.

James

---

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index d384f4f86c26..f4538d7a3016 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1230,6 +1230,8 @@ config SCSI_LPFC
tristate "Emulex LightPulse Fibre Channel Support"
depends on PCI && SCSI
depends on SCSI_FC_ATTRS
+   depends on NVME_TARGET_FC || NVME_TARGET_FC=n
+   depends on NVME_FC || NVME_FC=n
select CRC_T10DIF
---help---
   This lpfc driver supports the Emulex LightPulse
diff --git a/drivers/scsi/aic7xxx/Makefile b/drivers/scsi/aic7xxx/Makefile
index 741d81861d17..07b60a780c06 100644
--- a/drivers/scsi/aic7xxx/Makefile
+++ b/drivers/scsi/aic7xxx/Makefile
@@ -55,9 +55,9 @@ aicasm-7xxx-opts-$(CONFIG_AIC7XXX_REG_PRETTY_PRINT) := \
 
 ifeq ($(CONFIG_AIC7XXX_BUILD_FIRMWARE),y)
 $(obj)/aic7xxx_seq.h: $(src)/aic7xxx.seq $(src)/aic7xxx.reg 
$(obj)/aicasm/aicasm
-   $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic7xxx_reg.h \
+   $(obj)/aicasm/aicasm -I$(srctree)/$(src) -r $(obj)/aic7xxx_reg.h \
  $(aicasm-7xxx-opts-y) -o $(obj)/aic7xxx_seq.h \
- $(src)/aic7xxx.seq
+ $(srctree)/$(src)/aic7xxx.seq
 
 $(aic7xxx-gen-y): $(obj)/aic7xxx_seq.h
 else
@@ -72,14 +72,14 @@ aicasm-79xx-opts-$(CONFIG_AIC79XX_REG_PRETTY_PRINT) := \
 
 ifeq ($(CONFIG_AIC79XX_BUILD_FIRMWARE),y)
 $(obj)/aic79xx_seq.h: $(src)/aic79xx.seq $(src)/aic79xx.reg 
$(obj)/aicasm/aicasm
-   $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic79xx_reg.h \
+   $(obj)/aicasm/aicasm -I$(srctree)/$(src) -r $(obj)/aic79xx_reg.h \
  $(aicasm-79xx-opts-y) -o $(obj)/aic79xx_seq.h \
- $(src)/aic79xx.seq
+ $(srctree)/$(src)/aic79xx.seq
 
 $(aic79xx-gen-y): $(obj)/aic79xx_seq.h
 else
 $(obj)/aic79xx_reg_print.c: $(src)/aic79xx_reg_print.c_shipped
 endif
 
-$(obj)/aicasm/aicasm: $(src)/aicasm/*.[chyl]
-   $(MAKE) -C $(src)/aicasm
+$(obj)/aicasm/aicasm: $(srctree)/$(src)/aicasm/*.[chyl]
+   $(MAKE) -C $(srctree)/$(src)/aicasm OUTDIR=$(shell pwd)/$(obj)/aicasm/
diff --git a/drivers/scsi/aic7xxx/aicasm/Makefile 
b/drivers/scsi/aic7xxx/aicasm/Makefile
index b98c5c1056c3..45e2d49c1fff 100644
--- a/drivers/scsi/aic7xxx/aicasm/Makefile
+++ b/drivers/scsi/aic7xxx/aicasm/Makefile
@@ -1,19 +1,21 @@
 PROG=  aicasm
 
+OUTDIR ?= ./
+
 .SUFFIXES= .l .y .c .h
 
 CSRCS= aicasm.c aicasm_symbol.c
 YSRCS= aicasm_gram.y aicasm_macro_gram.y
 LSRCS= aicasm_scan.l aicasm_macro_scan.l
 
-GENHDRS=   aicdb.h $(YSRCS:.y=.h)
-GENSRCS=   $(YSRCS:.y=.c) $(LSRCS:.l=.c)
+GENHDRS=   $(addprefix ${OUTDIR}/,aicdb.h $(YSRCS:.y=.h))
+GENSRCS=   $(addprefix ${OUTDIR}/,$(YSRCS:.y=.c) $(LSRCS:.l=.c))
 
 SRCS=  ${CSRCS} ${GENSRCS}
 LIBS=  -ldb
 clean-files:= ${GENSRCS} ${GENHDRS} $(YSRCS:.y=.output) $(PROG)
 # Override default kernel CFLAGS.  This is a userland app.
-AICASM_CFLAGS:= -I/usr/include -I.
+AICASM_CFLAGS:= -I/usr/include -I. -I$(OUTDIR)
 LEX= flex
 YACC= bison
 YFLAGS= -d
@@ -32,22 +34,25 @@ YFLAGS+= -t -v
 LFLAGS= -d
 endif
 
-$(PROG):  ${GENHDRS} $(SRCS)
-   $(AICASM_CC) $(AICASM_CFLAGS) $(SRCS) -o $(PROG) $(LIBS)
+$(PROG):  $(OUTDIR) ${GENHDRS} $(SRCS)
+   $(AICASM_CC) $(AICASM_CFLAGS) $(SRCS) -o $(OUTDIR)/$(PROG) $(LIBS)
+
+$(OUTDIR):
+   mkdir -p $(OUTDIR)
 
-aicdb.h:
+$(OUTDIR)/aicdb.h:
@if [ -e "/usr/include/db4/db_185.h" ]; then\
-   echo "#include " > aicdb.h;   \
+   echo "#include " > $@;\
 elif [ -e "/usr/include/db3/db_185.h" ]; then  \
-   echo "#include " > aicdb.h;   \
+

[PATCH 2/4] scsi: Add VENDOR_SPECIFIC sense code definitions

2017-08-02 Thread Hannes Reinecke
Some older devices will return vendor specific sense codes, so
we should be adding a definition for it.

Signed-off-by: Hannes Reinecke 
---
 include/scsi/scsi_proto.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/scsi/scsi_proto.h b/include/scsi/scsi_proto.h
index 78215fd..06751a9 100644
--- a/include/scsi/scsi_proto.h
+++ b/include/scsi/scsi_proto.h
@@ -233,6 +233,7 @@ struct scsi_varlen_cdb_hdr {
 #define UNIT_ATTENTION  0x06
 #define DATA_PROTECT0x07
 #define BLANK_CHECK 0x08
+#define VENDOR_SPECIFIC 0x09
 #define COPY_ABORTED0x0a
 #define ABORTED_COMMAND 0x0b
 #define VOLUME_OVERFLOW 0x0d
-- 
1.8.5.6



[PATCH 1/4] raid_class: Add 'JBOD' RAID level

2017-08-02 Thread Hannes Reinecke
Not a real RAID level, but some HBAs support JBOD in addition to
the 'classical' RAID levels.

Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/raid_class.c  | 1 +
 include/linux/raid_class.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/scsi/raid_class.c b/drivers/scsi/raid_class.c
index 2c146b4..ea88906 100644
--- a/drivers/scsi/raid_class.c
+++ b/drivers/scsi/raid_class.c
@@ -157,6 +157,7 @@ static const char *raid_state_name(enum raid_state state)
{ RAID_LEVEL_5, "raid5" },
{ RAID_LEVEL_50, "raid50" },
{ RAID_LEVEL_6, "raid6" },
+   { RAID_LEVEL_JBOD, "jbod" },
 };
 
 static const char *raid_level_name(enum raid_level level)
diff --git a/include/linux/raid_class.h b/include/linux/raid_class.h
index 31e1ff6..ec86555 100644
--- a/include/linux/raid_class.h
+++ b/include/linux/raid_class.h
@@ -38,6 +38,7 @@ enum raid_level {
RAID_LEVEL_5,
RAID_LEVEL_50,
RAID_LEVEL_6,
+   RAID_LEVEL_JBOD,
 };
 
 struct raid_data {
-- 
1.8.5.6



[PATCH 0/4] mylex: Replace DAC960 block driver

2017-08-02 Thread Hannes Reinecke
Hi all,

as we're trying to get rid of the remaining request_fn drivers here's
a patchset to move the DAC960 driver to the SCSI stack.
The new driver is called 'mylex'.

The Mylex/DAC960 HBA comes in two flavours; the later one (V2) already
has a pretty complete SCSI emulation layer, so we just have to reformat
the command.
For for earlier ones (V1) we don't have a SCSI emulation layer for the
logical drives, so I've added a (pretty rudimentary, admittedly) SCSI
translation for them.
And the weird proc interface has been converted to sysfs attributes.

Tested with eXtremeRAID 1100 (for V1 Firmware) and Mylex AcceleRAID 170
(for V2 Firmware).

As usual, comments and reviews are welcome.

Hannes Reinecke (4):
  raid_class: Add 'JBOD' RAID level
  scsi: Add VENDOR_SPECIFIC sense code definitions
  scsi: add Mylex RAID controller
  block: Drop obsolete DAC960 driver

 Documentation/blockdev/README.DAC960 |  756 
 drivers/block/DAC960.c   | 7241 --
 drivers/block/DAC960.h   | 4415 -
 drivers/block/Kconfig|   12 -
 drivers/block/Makefile   |1 -
 drivers/scsi/Kconfig |   12 +
 drivers/scsi/Makefile|1 +
 drivers/scsi/mylex.c | 6025 
 drivers/scsi/mylex.h | 4029 +++
 drivers/scsi/raid_class.c|1 +
 include/linux/raid_class.h   |1 +
 include/scsi/scsi_proto.h|1 +
 12 files changed, 10070 insertions(+), 12425 deletions(-)
 delete mode 100644 Documentation/blockdev/README.DAC960
 delete mode 100644 drivers/block/DAC960.c
 delete mode 100644 drivers/block/DAC960.h
 create mode 100644 drivers/scsi/mylex.c
 create mode 100644 drivers/scsi/mylex.h

-- 
1.8.5.6



Dear friend,

2017-08-02 Thread Uba Jesuobo
Dear friend,
I'm sorry but happy to inform you about my success in getting those  funds 
under the cooperation of a new partner from Vietnam though i  tried my best to 
involve you in the business but God decided the whole  situations. Presently 
I'm in Vietnam for investment projects with my own share of the total sum. 

Meanwhile,i didn't forget your past efforts  and attempts to assist me in 
transferring those funds despite that it  failed us some how.

Now contact my secretary in Burkina faso her name is Ms.Lilian sambi  on her 
e-mail address  mslilian.sa...@yahoo.com  ask her to send you the total of 
$1,000,000.00 which i kept for your compensation for all the past  efforts and 
attempts to assist me in this matter. 

I appreciated  your efforts at that time very much. so feel free and get in 
touched  with my secretary Lilian sambi and instruct her where to send the 
amount  to you. 

Please do let me know immediately you receive it so that we  can share the joy 
after all the sufferings then. in the moment, I’m very busy here because of the 
investment projects  which I and the new partner are having at hand, finally, 
remember that I  had forwarded instruction to the secretary on your behalf to 
receive  that money, so feel free to get in touch with Ms.Lilian sambi. she  
will send the amount to you without any delay.
Regards,
Uba Jesuobo


Re: [PATCH 2/2] lpfc: support nvmet_fc defer_rcv callback

2017-08-02 Thread Johannes Thumshirn
On Wed, Aug 02, 2017 at 10:32:20AM +0200, Johannes Thumshirn wrote:
> On Tue, Aug 01, 2017 at 03:12:40PM -0700, James Smart wrote:
> > This patch is intended to enter the kernel through the nvme block
> > tree which pulls in the nvmet_fc api change at the same time. It is
> > not to be merged via the scsi trees without the latest nvme support
> > in it.
> 
> This should be placed below the '---' separator, so git won't pick it up and
> preserve it in the history.

Btw, I just found out and thought it's worth sharing: You can use 'git notes'
for these notes and if you use git format-patch --notes git automatically
places you r notes underneath the separator.

Byte,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850


tcm fc Asynchronous Event Notifications

2017-08-02 Thread Lv, Shuo
Hi, does the TCM support the Asynchronous Event Notifications function?



Re: [PATCH 2/2] lpfc: support nvmet_fc defer_rcv callback

2017-08-02 Thread Johannes Thumshirn
On Tue, Aug 01, 2017 at 03:12:40PM -0700, James Smart wrote:
> This patch is intended to enter the kernel through the nvme block
> tree which pulls in the nvmet_fc api change at the same time. It is
> not to be merged via the scsi trees without the latest nvme support
> in it.

This should be placed below the '---' separator, so git won't pick it up and
preserve it in the history.

[...]

>  
>   len += snprintf(buf+len, PAGE_SIZE-len,
> - "FCP: Rcv %08x Release %08x Drop %08x\n",
> + "FCP: Rcv %08x Defer %08x Release %08x "
> + "Drop %08x\n",

Please don't split the string across lines, it makes grepping hard.
Checkpatch actually warns you about that.

>   atomic_read(&tgtp->rcv_fcp_cmd_in),
> + atomic_read(&tgtp->rcv_fcp_cmd_defer),
>   atomic_read(&tgtp->xmt_fcp_release),
>   atomic_read(&tgtp->rcv_fcp_cmd_drop));
>  
> diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c 
> b/drivers/scsi/lpfc/lpfc_debugfs.c
> index 5cc8b0f7d885..744f3f395b64 100644
> --- a/drivers/scsi/lpfc/lpfc_debugfs.c
> +++ b/drivers/scsi/lpfc/lpfc_debugfs.c
> @@ -782,8 +782,11 @@ lpfc_debugfs_nvmestat_data(struct lpfc_vport *vport, 
> char *buf, int size)
>   atomic_read(&tgtp->xmt_ls_rsp_error));
>  
>   len += snprintf(buf + len, size - len,
> - "FCP: Rcv %08x Drop %08x\n",
> + "FCP: Rcv %08x Defer %08x Release %08x "
> + "Drop %08x\n",
>   atomic_read(&tgtp->rcv_fcp_cmd_in),
> + atomic_read(&tgtp->rcv_fcp_cmd_defer),
> + atomic_read(&tgtp->xmt_fcp_release),
>   atomic_read(&tgtp->rcv_fcp_cmd_drop));

Ditto.


[...]

> + tgtp = (struct lpfc_nvmet_tgtport *)phba->targetport->private;

No need to cast from void *

[...]

> + /* Processing of FCP command is deferred */
> + if (rc == -EOVERFLOW) {
> + lpfc_nvmeio_data(phba,
> +  "NVMET RCV BUSY: xri x%x sz %d from %06x\n",
> +  oxid, size, sid);
> + /* defer reposting rcv buffer till .defer_rcv callback */
> + ctxp->rqb_buffer = (void *)nvmebuf;

nvmebuf is a 'struct rqb_dmabuf *' and ctxp->rqb_buffer expects 'struct
rqb_dmabuf *', why do you need a void * cast here?


-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850


[PATCH] scsi: add const to bin_attribute structures

2017-08-02 Thread Bhumika Goyal
Add const to bin_attribute structures as they are only passed to the
functions sysfs_{remove/create}_bin_file. The arguments passed are of
type const, so declare the structures to be const.

Done using Coccinelle.

@m disable optional_qualifier@
identifier s;
position p;
@@
static struct bin_attribute s@p={...};

@okay1@
position p;
identifier m.s;
@@
(
sysfs_create_bin_file(...,&s@p,...)
|
sysfs_remove_bin_file(...,&s@p,...)
)

@bad@
position p!={m.p,okay1.p};
identifier m.s;
@@
s@p

@change depends on !bad disable optional_qualifier@
identifier m.s;
@@
static
+const
struct bin_attribute s={...};

Signed-off-by: Bhumika Goyal 
---
 drivers/scsi/3w-sas.c | 4 ++--
 drivers/scsi/ipr.c| 2 +-
 drivers/scsi/lpfc/lpfc_attr.c | 6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index b150e13..5328a03 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -116,7 +116,7 @@ static ssize_t twl_sysfs_aen_read(struct file *filp, struct 
kobject *kobj,
 } /* End twl_sysfs_aen_read() */
 
 /* aen_read sysfs attribute initializer */
-static struct bin_attribute twl_sysfs_aen_read_attr = {
+static const struct bin_attribute twl_sysfs_aen_read_attr = {
.attr = {
.name = "3ware_aen_read",
.mode = S_IRUSR,
@@ -147,7 +147,7 @@ static ssize_t twl_sysfs_compat_info(struct file *filp, 
struct kobject *kobj,
 } /* End twl_sysfs_compat_info() */
 
 /* compat_info sysfs attribute initializer */
-static struct bin_attribute twl_sysfs_compat_info_attr = {
+static const struct bin_attribute twl_sysfs_compat_info_attr = {
.attr = {
.name = "3ware_compat_info",
.mode = S_IRUSR,
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index b0c68d2..8f04f66 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -4206,7 +4206,7 @@ static ssize_t ipr_next_async_err_log(struct file *filep, 
struct kobject *kobj,
return count;
 }
 
-static struct bin_attribute ipr_ioa_async_err_log = {
+static const struct bin_attribute ipr_ioa_async_err_log = {
.attr = {
.name = "async_err_log",
.mode = S_IRUGO | S_IWUSR,
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 4ed48ed..be04408 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -3974,7 +3974,7 @@ static DEVICE_ATTR(lpfc_stat_data_ctrl, S_IRUGO | S_IWUSR,
return index;
 }
 
-static struct bin_attribute sysfs_drvr_stat_data_attr = {
+static const struct bin_attribute sysfs_drvr_stat_data_attr = {
.attr = {
.name = "lpfc_drvr_stat_data",
.mode = S_IRUSR,
@@ -5368,7 +5368,7 @@ struct device_attribute *lpfc_vport_attrs[] = {
return count;
 }
 
-static struct bin_attribute sysfs_ctlreg_attr = {
+static const struct bin_attribute sysfs_ctlreg_attr = {
.attr = {
.name = "ctlreg",
.mode = S_IRUSR | S_IWUSR,
@@ -5426,7 +5426,7 @@ struct device_attribute *lpfc_vport_attrs[] = {
return -EPERM;
 }
 
-static struct bin_attribute sysfs_mbox_attr = {
+static const struct bin_attribute sysfs_mbox_attr = {
.attr = {
.name = "mbox",
.mode = S_IRUSR | S_IWUSR,
-- 
1.9.1



Re: [PATCH 1/2] nvmet_fc: add defer_req callback for deferment of cmd buffer return

2017-08-02 Thread Johannes Thumshirn
On Tue, Aug 01, 2017 at 03:12:39PM -0700, James Smart wrote:
> @@ -463,9 +472,9 @@ static struct nvmet_fc_fcp_iod *
>  nvmet_fc_alloc_fcp_iod(struct nvmet_fc_tgt_queue *queue)
>  {
>   static struct nvmet_fc_fcp_iod *fod;
> - unsigned long flags;
>  
> - spin_lock_irqsave(&queue->qlock, flags);
> + /* Caller must hold queue->qlock */
+   lockped_assert_held(&queue->qlock); 
So we can check if the caller really holds the queue lock.

> +
>   fod = list_first_entry_or_null(&queue->fod_list,
>   struct nvmet_fc_fcp_iod, fcp_list);
>   if (fod) {

[...]

> + for (;;) {
> + deferfcp = list_first_entry_or_null(&queue->pending_cmd_list,
> + struct nvmet_fc_defer_fcp_req, req_list);
> + if (!deferfcp)
> + break;

while ((deferfcp = list_first_entry_or_null(&queue->pending_cmd_list,
struct nvmet_fc_defer_fcp_req,
req_list)) != NULL) {
?

Other than that,
Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850


Re: [PATCH v2 00/13] mpt3sas driver NVMe support:

2017-08-02 Thread Hannes Reinecke
On 07/14/2017 03:22 PM, Suganath Prabu S wrote:
> Ventura Series controller are Tri-mode. The controller and
> firmware are capable of supporting NVMe devices and
> PCIe switches to be connected with the controller. This
> patch set adds driver level support for NVMe devices and
> PCIe switches.
> 
> Suganath Prabu S (13):
>   mpt3sas: Update MPI Header
>   mpt3sas: Add nvme device support in slave alloc, target alloc and
> probe
>   mpt3sas: SGL to PRP Translation for I/Os to NVMe  devices
>   mpt3sas: Added support for nvme encapsulated request message.
>   mpt3sas: API 's to support NVMe drive addition to SML
>   mpt3sas: API's to remove nvme drive from sml
>   mpt3sas: Handle NVMe PCIe device related events generated
>from firmware.
>   mpt3sas: Set NVMe device queue depth as 128
>   mpt3sas: scan and add nvme device after controller reset
>   mpt3as: Add-Task-management-debug-info-for-NVMe-drives.
>   mpt3sas: NVMe drive support for BTDHMAPPING ioctl command and log
> info
>   mpt3sas: Fix nvme drives checking for tlr.
>   mpt3sas: Update mpt3sas driver version.
> 
>  drivers/scsi/mpt3sas/mpi/mpi2.h  |   43 +-
>  drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  647 ++-
>  drivers/scsi/mpt3sas/mpi/mpi2_init.h |   11 +-
>  drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  331 ++-
>  drivers/scsi/mpt3sas/mpi/mpi2_pci.h  |  142 +++
>  drivers/scsi/mpt3sas/mpi/mpi2_tool.h |   14 +-
>  drivers/scsi/mpt3sas/mpt3sas_base.c  |  710 +++-
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  171 +++-
>  drivers/scsi/mpt3sas/mpt3sas_config.c|  100 ++
>  drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  158 ++-
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 1874 
> --
>  drivers/scsi/mpt3sas/mpt3sas_warpdrive.c |2 +-
>  12 files changed, 4063 insertions(+), 140 deletions(-)
>  create mode 100644 drivers/scsi/mpt3sas/mpi/mpi2_pci.h
> 
I'm not happy with this approach.
NVMe devices should _not_ appear as SCSI devices; this will just confuse
matters _and_ will be incompatible with 'normal' NVMe devices.

Rather I would like to see the driver to hook into the existing NVMe
framework (which essentially means to treat the mpt3sas as a weird
NVMe-over-Fabrics HBA), and expose the NVMe devices like any other NVMe HBA.

I'm sorry that you'll have to redo your patchset (again), but this is
the only way I see how this patchset can be brought forward.

I'd be happy to discuss implementation details with you.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


[Bug 196543] Adaptec 6405H can not understand Queue full message from Disks.

2017-08-02 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196543

Jack Wang (xjtu...@gmail.com) changed:

   What|Removed |Added

 CC||xjtu...@gmail.com

--- Comment #3 from Jack Wang (xjtu...@gmail.com) ---
Hi Kazufumi,

Could you send out dmesg with logging_level=0xfff for scsi_host on microsemi
HBA when queue full condition happens?

-- 
You are receiving this mail because:
You are the assignee for the bug.