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)
next prev parent 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).