From: Tejun Heo <htejun@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: akpm@osdl.org, jgarzik@pobox.com, linux-ide@vger.kernel.org
Subject: Re: [PATCH] libata: Handle SATA bridges better
Date: Mon, 21 May 2007 16:52:42 +0200 [thread overview]
Message-ID: <4651B23A.40207@gmail.com> (raw)
In-Reply-To: <20070521154741.490bcdb6@the-village.bc.nu>
Alan Cox wrote:
>> I'm not sure this is correct. The SATA bridge can be at the far side of
>> PATA cable near to the drive. ie.
>>
>> PATA host <========= PATA cable ==========> P/SATA bridge : SATA drive
>
> Yes
>
>> In this case, most of the cable is PATA and cable detection matters.
>
> The cable detection is done by the drive not the bridge, and for the
> boards I've got access to this means that the cable detection doesn't work
> at all. This is a big problem with things like the VIA C7 embedded boards
> which currently run at the wrong speeds as a result.
I think host side detection should work as long as the bridge properly
releases CBLID after IDENTIFY. Drive side detection seems hopeless
unless the bridge modifies IDENTIFY data accordingly. Maybe the best we
can do here is allowing user to select transfer mode. :-(
>> Another problem is that there are still codes which interpret ap->cbl ==
>> ATA_CBL_SATA as SATA host port. They need to be fixed first before
>> using ap->cbl for the actual cable type.
>
> I thought we had those all sorted now. A grep shows there is nobody doing
> conditional checking off the ap->cbl cable in drivers/ata any more. They
> did in the past - which is this patch got held up - but no longer that I
> can see.
Hmm... I was looking at sata_scr_valid(). I think this needs to be
converted to ATA_FLAG_SATA test too.
--
tejun
next prev parent reply other threads:[~2007-05-21 14:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-21 14:13 [PATCH] libata: Handle SATA bridges better Alan Cox
2007-05-21 14:22 ` Tejun Heo
2007-05-21 14:47 ` Alan Cox
2007-05-21 14:52 ` Tejun Heo [this message]
2007-05-21 16:14 ` Alan Cox
2007-05-21 16:12 ` Tejun Heo
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=4651B23A.40207@gmail.com \
--to=htejun@gmail.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--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 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).