All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Alan <alan@lxorguk.ukuu.org.uk>, Jeff Garzik <jeff@garzik.org>,
	linux-ide@vger.kernel.org, stable@kernel.org,
	Mark Lord <mlord@pobox.com>,
	Sergei Shtylyov <sshtylyov@ru.mvista.com>
Subject: Re: [PATCH libata-dev#upstream-fixes] pata_amd: fix an obvious bug in cable detection
Date: Sun, 25 Feb 2007 18:39:36 +0100	[thread overview]
Message-ID: <200702251839.36205.bzolnier@gmail.com> (raw)
In-Reply-To: <45E19AE7.2020206@gmail.com>


On Sunday 25 February 2007, Tejun Heo wrote:
> [cc'ing Mark, Bart and Sergei. Hi]
> 
> Alan wrote:
> >>> This makes unreliable cable detection even more unreliable.  Please
> >>> consider for -stable.  Thanks.
> > 
> > At minimum you also need to stop doing drive side detect for PATA_CBL_80
> > as many controllers don't do both so if you've got host side detect that
> > is what you must trust.
> > 
> > Fixed that in my internal tree and it seems happier
> 
> It seems libata is wrong about device side cable detection.  Device side
> cable detection tries to detect host side capacitor connected to PDIAG-,
> depends on the slave device releasing PDIAG- signal.
> 
> According to Annex B of ATA/ATAPI-5, IDENTIFY should be issued to the
> slave device first to ensure that it releases PDIAG- and then use the
> cable detection result from the master device.  As we IDENTIFY master
> first right after reset, slave if present is driving PDIAG-, so the
> master on IDENTIFY always thinks the capacitor is present and 40c limit
> is always applied.
> 
> IDE is better off because it doesn't reset before IDENTIFYing and it's
> likely that BIOS has issued some commands to the slave device prior to
> passing control to OS thus making it release PDIAG-.
> 
> 1. Device side cable detection can only be used to limit speed because
> if motherboard doesn't have capacitor attached to PDIAG-, the test
> result always indicates 80c.
> 
> 2. Host side detection involves issuing commands to attached devices
> because it depends on the slave device releasing PDIAG-, so most
> controllers do cable detection in BIOS and just put the result in PCI
> config region or wherever.  We dunno how BIOS does it exactly but many
> of them probably consider device side detection result as well.
> 
> So, considering #1 and #2, it might be best to just believe what the
> controller (BIOS) says and not bother about device side detection.  In
> fact, we've been effectively ignoring device side detection result
> before my "fix" for device side cable detection.
> 
> What do you think?

Why can't libata do the right thing and just send IDENTIFY command
to the slave device first?

Bart

  reply	other threads:[~2007-02-25 17:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05  8:01 [PATCH libata-dev#upstream-fixes] pata_amd: fix an obvious bug in cable detection Tejun Heo
2007-02-05 11:28 ` Alan
2007-02-25  1:52 ` Jeff Garzik
2007-02-25 13:29   ` Alan
2007-02-25 14:19     ` Tejun Heo
2007-02-25 17:39       ` Bartlomiej Zolnierkiewicz [this message]
2007-02-25 17:41         ` Tejun Heo
2007-02-25 18:50           ` Bartlomiej Zolnierkiewicz
2007-02-26 17:27           ` Alan
2007-02-25 19:13       ` Alan

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=200702251839.36205.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=mlord@pobox.com \
    --cc=sshtylyov@ru.mvista.com \
    --cc=stable@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.