linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sumit Saxena <sumit.saxena@broadcom.com>
To: Hannes Reinecke <hare@suse.de>, linux-scsi@vger.kernel.org
Cc: martin.petersen@oracle.com, thenzl@redhat.com,
	jejb@linux.vnet.ibm.com,
	Kashyap Desai <kashyap.desai@broadcom.com>
Subject: RE: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach
Date: Mon, 17 Oct 2016 17:49:19 +0530	[thread overview]
Message-ID: <2cd63d31d86ebbfbb41a0a6311324c79@mail.gmail.com> (raw)
In-Reply-To: <cba7dc68-e472-bece-a71a-88db54160829@suse.de>

>-----Original Message-----
>From: Hannes Reinecke [mailto:hare@suse.de]
>Sent: Monday, October 17, 2016 5:01 PM
>To: Sumit Saxena; linux-scsi@vger.kernel.org
>Cc: martin.petersen@oracle.com; thenzl@redhat.com;
jejb@linux.vnet.ibm.com;
>kashyap.desai@broadcom.com
>Subject: Re: [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI
>shutdown/detach
>
>On 10/17/2016 12:24 PM, Sumit Saxena wrote:
>> This patch addresses the issue of driver firing DCMDs in PCI
>> shutdown/detach path irrespective of firmware state.
>> Driver will check for whether firmware is operational state or not
>> before firing DCMDs. If firmware is in unrecoverbale state or does not
>> become operational within specfied time, driver will skip firing
>> DCMDs.
>>
>> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 46
>+++++++++++++++++++++++++++++
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c |  9 ++++--
>>  2 files changed, 52 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 9ff57de..092387f 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -6248,6 +6248,32 @@ fail_reenable_msix:
>>  #define megasas_resume	NULL
>>  #endif
>>
>> +static inline int
>> +megasas_wait_for_adapter_operational(struct megasas_instance
>> +*instance) {
>> +	int wait_time = MEGASAS_RESET_WAIT_TIME * 2;
>> +	int i;
>> +
>> +	for (i = 0; i < wait_time; i++) {
>> +		if (atomic_read(&instance->adprecovery)
>> +			== MEGASAS_HBA_OPERATIONAL)
>> +			break;
>> +
>> +		if (!(i % MEGASAS_RESET_NOTICE_INTERVAL))
>> +			dev_notice(&instance->pdev->dev, "waiting for
>controller reset to
>> +finish\n");
>> +
>> +		msleep(1000);
>> +	}
>> +
>> +	if (atomic_read(&instance->adprecovery) !=
>MEGASAS_HBA_OPERATIONAL) {
>> +		dev_info(&instance->pdev->dev, "%s timed out while waiting
for
>HBA to recover.\n",
>> +			__func__);
>> +		return 1;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>  /**
>>   * megasas_detach_one -	PCI hot"un"plug entry point
>>   * @pdev:		PCI device structure
>> @@ -6272,9 +6298,18 @@ static void megasas_detach_one(struct pci_dev
>*pdev)
>>  	if (instance->fw_crash_state != UNAVAILABLE)
>>  		megasas_free_host_crash_buffer(instance);
>>  	scsi_remove_host(instance->host);
>> +
>> +	msleep(1000);
>> +	if ((atomic_read(&instance->adprecovery) ==
>MEGASAS_HW_CRITICAL_ERROR)
>> +		|| ((atomic_read(&instance->adprecovery)
>> +			!= MEGASAS_HBA_OPERATIONAL) &&
>> +		megasas_wait_for_adapter_operational(instance)))
>> +		goto skip_firing_dcmds;
>> +
>>  	megasas_flush_cache(instance);
>>  	megasas_shutdown_controller(instance,
>MR_DCMD_CTRL_SHUTDOWN);
>>
>> +skip_firing_dcmds:
>>  	/* cancel the delayed work if this work still in queue*/
>>  	if (instance->ev != NULL) {
>>  		struct megasas_aen_event *ev = instance->ev;
>Why not move the 'msleep' and 'atomic_read' into the call to
>megasas_wait_for_adapter_operational?
I will rectify this in next version of this patch.

>Plus I'm not sure if the unconditional 'msleep' is a good idea here;
maybe one
>should read 'adprecovery' first and _then_ call msleep if required?
Agreed.. I will cleanup this and resend the patch.

Thanks,
Sumit
>
>Cheers,
>
>Hannes
>--
>Dr. Hannes Reinecke		   Teamlead Storage & Networking
>hare@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)

  reply	other threads:[~2016-10-17 12:19 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 10:24 [PATCH 0/7] megaraid_sas: Updates for scsi-next Sumit Saxena
2016-10-17 10:24 ` [PATCH 1/7] megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset Sumit Saxena
2016-10-17 11:29   ` Hannes Reinecke
2016-10-17 12:43   ` Tomas Henzl
2016-10-17 10:24 ` [PATCH 2/7] megaraid_sas: Send correct PhysArm to FW for R1 VD downgrade Sumit Saxena
2016-10-17 11:29   ` Hannes Reinecke
2016-10-17 12:50   ` Tomas Henzl
2016-10-17 10:24 ` [PATCH 3/7] megaraid_sas: Do not fire DCMDs during PCI shutdown/detach Sumit Saxena
2016-10-17 11:31   ` Hannes Reinecke
2016-10-17 12:19     ` Sumit Saxena [this message]
2016-10-17 10:24 ` [PATCH 4/7] megaraid_sas: Send SYNCHRONIZE_CACHE command to firmware Sumit Saxena
2016-10-17 11:34   ` Hannes Reinecke
2016-10-17 12:13     ` Sumit Saxena
2016-10-17 13:01     ` Ric Wheeler
2016-10-17 13:31       ` Sumit Saxena
2016-10-17 15:55       ` Christoph Hellwig
2016-10-17 16:08         ` Ric Wheeler
2016-10-17 16:23           ` Ewan D. Milne
2016-10-17 16:20       ` James Bottomley
2016-10-17 16:27         ` Ric Wheeler
2016-10-17 17:19           ` James Bottomley
2016-10-17 17:30             ` Ric Wheeler
2016-10-17 17:36             ` Kashyap Desai
2016-10-17 17:51               ` James Bottomley
2016-10-18 13:56                 ` Tomas Henzl
2016-10-19  9:50                   ` Ching Huang
2016-10-19 12:55                     ` Tomas Henzl
2016-10-19 18:07                       ` Raghava Aditya Renukunta
2016-10-21 16:30                         ` Tomas Henzl
2016-10-25  2:02                       ` Martin K. Petersen
     [not found]                         ` <CAKiknE_MM88eVON1g_qy7wbb2fkxdAs6O0SRSzN-RbQqSvx1eA@mail.gmail.com>
2016-10-27  2:07                           ` Martin K. Petersen
2016-10-18 18:47                 ` Sumit Saxena
2016-10-17 16:29         ` Ric Wheeler
2016-10-17 13:13   ` Tomas Henzl
2016-10-17 13:28     ` Sumit Saxena
2016-10-17 13:57       ` Tomas Henzl
2016-10-17 14:25         ` Sumit Saxena
2016-10-18 13:07         ` Ric Wheeler
2016-10-18 13:22           ` Sumit Saxena
2016-10-17 10:24 ` [PATCH 5/7] megaraid_sas: driver version upgrade Sumit Saxena
2016-10-17 11:35   ` Hannes Reinecke
2016-10-17 12:20     ` Sumit Saxena
2016-10-17 10:24 ` [PATCH 6/7] MAINTAINERS: Update megaraid maintainers list Sumit Saxena
2016-10-17 11:37   ` Hannes Reinecke
2016-10-17 10:24 ` [PATCH 7/7] megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map Sumit Saxena
2016-10-17 11:37   ` Hannes Reinecke
2016-10-17 13:23   ` Tomas Henzl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cd63d31d86ebbfbb41a0a6311324c79@mail.gmail.com \
    --to=sumit.saxena@broadcom.com \
    --cc=hare@suse.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=thenzl@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).