From: Sujit Reddy Thumma <sthumma@codeaurora.org>
To: Santosh Y <santoshsy@gmail.com>
Cc: Vinayak Holikatti <vinholikatti@gmail.com>,
"James E.J. Bottomley" <JBottomley@parallels.com>,
linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V2 4/4] scsi: ufs: Improve UFS fatal error handling
Date: Thu, 04 Jul 2013 13:14:25 +0530 [thread overview]
Message-ID: <51D527D9.5070509@codeaurora.org> (raw)
In-Reply-To: <CALMYJDszHtT53BHDgepw5D2Sk_Zz+vWedY_Bucd4-FBCWcaYeA@mail.gmail.com>
On 7/3/2013 10:22 PM, Santosh Y wrote:
>> +
>> +/**
>> + * ufshcd_fatal_err_handler - handle fatal errors
>> + * @work: pointer to work structure
>> */
>> static void ufshcd_fatal_err_handler(struct work_struct *work)
>> {
>> struct ufs_hba *hba;
>> + unsigned long flags;
>> + u32 err_xfer = 0;
>> + u32 err_tm = 0;
>> + int err;
>> +
>> hba = container_of(work, struct ufs_hba, feh_workq);
>>
>> - /* check if reset is already in progress */
>> - if (hba->ufshcd_state != UFSHCD_STATE_RESET)
>> - ufshcd_do_reset(hba);
>> + spin_lock_irqsave(hba->host->host_lock, flags);
>> + if (hba->ufshcd_state == UFSHCD_STATE_RESET) {
>> + /* complete processed requests and exit */
>> + ufshcd_transfer_req_compl(hba);
>> + ufshcd_tmc_handler(hba);
>> + spin_unlock_irqrestore(hba->host->host_lock, flags);
>> + return;
>
> I could not go through this patch yet, please check if it needs to
> wait here until the state is 'operational' or 'error'.
> The 'reset' state might be due to the device reset also.
As of now reset is scheduled only in two contexts -
1) Fatal error handling
2) SCSI error handling
If scsi error handling is in progress it changes the state to
UFSHCD_STATE_RESET. If fatal error interrupt is raised it checks
whether the state is operational or not before scheduling the work.
So in any case, there is no race between fatal error handler
and the scsi error handler and hence there is no need any wait here.
static void ufshcd_err_handler(struct ufs_hba *hba)
{
...
fatal_eh:
- hba->ufshcd_state = UFSHCD_STATE_ERROR;
- schedule_work(&hba->feh_workq);
+ /* handle fatal errors only when link is functional */
+ if (hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL) {
+ /* block commands from midlayer */
+ scsi_block_requests(hba->host);
+
+ /* block commands at driver layer until error is handled */
+ hba->ufshcd_state = UFSHCD_STATE_ERROR;
+ schedule_work(&hba->feh_workq);
+ }
}
>
>> + }
>> +
>> + hba->ufshcd_state = UFSHCD_STATE_RESET;
>> + ufshcd_error_autopsy_transfer_req(hba, &err_xfer);
>> + ufshcd_error_autopsy_task_req(hba, &err_tm);
>> +
>
>
--
Regards,
Sujit
prev parent reply other threads:[~2013-07-04 7:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 18:35 [PATCH V2 0/4] scsi: ufs: Improve UFS error handling Sujit Reddy Thumma
2013-06-28 18:35 ` [PATCH V2 1/4] scsi: ufs: Fix broken task management command implementation Sujit Reddy Thumma
2013-06-28 18:35 ` [PATCH V2 2/4] scsi: ufs: Fix hardware race conditions while aborting a command Sujit Reddy Thumma
2013-06-28 18:35 ` [PATCH V2 3/4] scsi: ufs: Fix device and host reset methods Sujit Reddy Thumma
2013-07-03 5:49 ` Santosh Y
2013-07-03 16:35 ` Sujit Reddy Thumma
2013-06-28 18:35 ` [PATCH V2 4/4] scsi: ufs: Improve UFS fatal error handling Sujit Reddy Thumma
2013-07-03 16:52 ` Santosh Y
2013-07-04 7:44 ` Sujit Reddy Thumma [this message]
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=51D527D9.5070509@codeaurora.org \
--to=sthumma@codeaurora.org \
--cc=JBottomley@parallels.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=santoshsy@gmail.com \
--cc=vinholikatti@gmail.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).