From: Tejun Heo <tj@kernel.org>
To: "Huang, Shane" <Shane.Huang@amd.com>
Cc: jgarzik@pobox.com, linux-ide@vger.kernel.org
Subject: Re: [PATCH #upstream, v2] ahci: Implement SATA AHCI FIS-based switching support
Date: Wed, 02 Sep 2009 10:58:43 +0900 [thread overview]
Message-ID: <4A9DD153.5050106@kernel.org> (raw)
In-Reply-To: <C8E4BD7D001E44499280E0884BD9DB30FC984D@sshaexmb1.amd.com>
Huang, Shane wrote:
> Hi Tejun,
>
>
>> -----Original Message-----
>> From: Tejun Heo [mailto:tj@kernel.org]
>>> I find that ahci_pmp_detach() will be called for each SATA port
>>> during the initialization, right after print:
>>>> ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp fbs...
>>> so will ahci_disable_fbs() be called, which leads to the trigger
>>> of WARN_ON().
>> Ah.. right. ahci_port_resume() does that to make sure that all PMP
>> bits are cleared on init. Hmmm... probably it would be better to make
>> ahci_disable_fbs() to just do it regardless of libata thinks whether
>> PMP is attached or not. After resume from STR, we shouldn't be
>> assuming anything about the controller state.
>
>
> I have added sata_pmp_attached() check for both ahci_enable_fbs()
> and ahci_disable_fbs(), because I believe it's necessary.
>
> if (!pp->fbs_supported || !sata_pmp_attached(ap))
> return;
>
> What do you mean to make it better? How to? I do not catch your
> above words very much...
I meant that sata_pmp_attached() is a driver state and might not match
the controller state after resume which is why the ahci driver calls
detach in the first place regardless of sata_pmp_attached(), so it
might be better to check the register directly and set or clear it
regardless of sata_pmp_attached().
Thanks.
--
tejun
next prev parent reply other threads:[~2009-09-02 1:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 4:45 [PATCH #upstream, v2] ahci: Implement SATA AHCI FIS-based switching support Shane Huang
2009-08-31 8:01 ` Tejun Heo
2009-09-01 12:22 ` Huang, Shane
2009-09-01 12:28 ` Tejun Heo
2009-09-01 13:08 ` Huang, Shane
2009-09-01 13:14 ` Tejun Heo
2009-09-02 1:55 ` Huang, Shane
2009-09-02 1:58 ` Tejun Heo [this message]
2009-09-02 2:32 ` Huang, Shane
2009-09-02 2:40 ` Tejun Heo
2009-09-02 6:42 ` Huang, Shane
2009-09-02 6:49 ` Tejun Heo
2009-09-02 6:58 ` Huang, Shane
2009-09-03 4:53 ` Huang, Shane
2009-09-03 6:04 ` Tejun Heo
2009-09-04 2:25 ` Huang, Shane
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=4A9DD153.5050106@kernel.org \
--to=tj@kernel.org \
--cc=Shane.Huang@amd.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.