From: Tejun Heo <htejun@gmail.com>
To: Lin Mac <mkl0301@gmail.com>
Cc: cbouatmailru@gmail.com, linux-arm-kernel@lists.infradead.org,
jgarzik@pobox.com, linux-ide@vger.kernel.org
Subject: Re: Cannot detect SATA disks w/ CONFIG_SATA_PMP w/o actually using SATA multiplier
Date: Wed, 01 Dec 2010 10:45:25 +0100 [thread overview]
Message-ID: <4CF61935.2080501@gmail.com> (raw)
In-Reply-To: <AANLkTinyJdTYXgpfvmw8vRBEFOc+SdCKe9hBZbGk1oLd@mail.gmail.com>
Hello,
On 12/01/2010 06:53 AM, Lin Mac wrote:
> While using multiplier with CONFIG_SATA_PMP enabled, or using disks directly
> without CONFIG_SATA_PMP have no issue.
>
> It is because sata_srst_pmp always return SATA_PMP_CTRL_PORT(15),
> which casued ahci_do_softreset with pmp 15, which is not needed for
> disks connected directly.
SRST w/ PMP==15 is the standard defined way to probe devices for PMP
capable controllers.
> With SPMH3726-P rev:2.1.2, ata_dev_classify would report ATA_DEV_UNKNOWN on
> ahci_hardreset. While with a Segate Barracuda 1TB SATA HD, it is ATA_DEV_ATA.
> Therefore, the pmp returned by sata_srst_pmp should depends on the class
> reported by ahci_hardreset.
IIRC, PMP should return the signature of the first device after
hardreset. At any rate, the standard sanctioned way to probe is SRST
w/ PMP==15.
> This patch does 2 things:
> 1. ata_eh_reset calls ata_do_reset upon SRST without clearing classes, to be
> used by sata_srst_pmp to decide pmp.
> 2. sata_srst_pmp returns SATA_PMP_CTRL_PORT only when class is ATA_DEV_PMP or
> ATA_DEV_UNKNOWN
So, no, this isn't acceptable. You're making the behavior deviate
from the standard for all controllers and devices to work around a
faulty, rather obscure controller. If you want to work around, please
implement a workaround which is specific to the controller in
question.
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: htejun@gmail.com (Tejun Heo)
To: linux-arm-kernel@lists.infradead.org
Subject: Cannot detect SATA disks w/ CONFIG_SATA_PMP w/o actually using SATA multiplier
Date: Wed, 01 Dec 2010 10:45:25 +0100 [thread overview]
Message-ID: <4CF61935.2080501@gmail.com> (raw)
In-Reply-To: <AANLkTinyJdTYXgpfvmw8vRBEFOc+SdCKe9hBZbGk1oLd@mail.gmail.com>
Hello,
On 12/01/2010 06:53 AM, Lin Mac wrote:
> While using multiplier with CONFIG_SATA_PMP enabled, or using disks directly
> without CONFIG_SATA_PMP have no issue.
>
> It is because sata_srst_pmp always return SATA_PMP_CTRL_PORT(15),
> which casued ahci_do_softreset with pmp 15, which is not needed for
> disks connected directly.
SRST w/ PMP==15 is the standard defined way to probe devices for PMP
capable controllers.
> With SPMH3726-P rev:2.1.2, ata_dev_classify would report ATA_DEV_UNKNOWN on
> ahci_hardreset. While with a Segate Barracuda 1TB SATA HD, it is ATA_DEV_ATA.
> Therefore, the pmp returned by sata_srst_pmp should depends on the class
> reported by ahci_hardreset.
IIRC, PMP should return the signature of the first device after
hardreset. At any rate, the standard sanctioned way to probe is SRST
w/ PMP==15.
> This patch does 2 things:
> 1. ata_eh_reset calls ata_do_reset upon SRST without clearing classes, to be
> used by sata_srst_pmp to decide pmp.
> 2. sata_srst_pmp returns SATA_PMP_CTRL_PORT only when class is ATA_DEV_PMP or
> ATA_DEV_UNKNOWN
So, no, this isn't acceptable. You're making the behavior deviate
from the standard for all controllers and devices to work around a
faulty, rather obscure controller. If you want to work around, please
implement a workaround which is specific to the controller in
question.
Thanks.
--
tejun
next prev parent reply other threads:[~2010-12-01 9:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 4:02 Cannot detect SATA disks w/ CONFIG_SATA_PMP w/o actually using SATA multiplier Lin Mac
2010-11-30 4:02 ` Lin Mac
2010-11-30 14:08 ` Tejun Heo
2010-11-30 14:08 ` Tejun Heo
2010-11-30 17:46 ` Lin Mac
2010-11-30 17:46 ` Lin Mac
2010-11-30 19:49 ` Tejun Heo
2010-11-30 19:49 ` Tejun Heo
2010-12-01 5:53 ` Lin Mac
2010-12-01 5:53 ` Lin Mac
2010-12-01 9:45 ` Tejun Heo [this message]
2010-12-01 9:45 ` Tejun Heo
2010-12-02 10:23 ` Lin Mac
2010-12-02 10:23 ` Lin Mac
2010-12-02 10:31 ` Tejun Heo
2010-12-02 10:31 ` Tejun Heo
2010-12-04 17:07 ` Lin Mac
2010-12-04 17:07 ` Lin Mac
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=4CF61935.2080501@gmail.com \
--to=htejun@gmail.com \
--cc=cbouatmailru@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=mkl0301@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 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.