From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: jgarzik@pobox.com, linux-ide@vger.kernel.org, stable@kernel.org
Subject: Re: [PATCH] pata_hpt3x2n: fix timing register masks (take 2)
Date: Sat, 05 Dec 2009 02:34:45 +0300 [thread overview]
Message-ID: <4B199C95.7080708@ru.mvista.com> (raw)
In-Reply-To: <20091204232923.6daacb23@lxorguk.ukuu.org.uk>
Hello.
Alan Cox wrote:
>> - the driver doesn't serialize access to the channels depending on the current
>> clock mode like the vendor drivers, so the clock turnaround is only executed
>> "optionally", not always as it should be;
>>
>
> The vendor driver I have uses that algorithm. I think I prefer your
> approach however !
>
>
Does it have the *ClockCapable() things? These functions seem to
implement command deferring much like hpt3x2n_qc_defer() does now.
>> - the wrong ports are written to when hpt3x2n_set_clock() is called for the
>> secondary channel;
>>
>
> Ouch.
>
Same as in the IDE driver... I really should have taken a closer look
at the libata driver earlier.
>> - hpt3x2n_set_clock() can inadvertently enable the disabled channels when
>> resetting the channel state machines.
>>
>
> Yep.
>
Same as in IDE driver too. I guess you've copied this from the vendor
driver that also does this.
>
>> Could you give this a bit of testing? I don't have HPT371N at hand, and it's
>> seated in the board with 66 MHz PCI anyway...
>>
>
> I'm not likely to have a chance to do so until next year.
>
That's a pity... well, then we probably have to commit it untested. :-)
MBR, Sergei
prev parent reply other threads:[~2009-12-04 23:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 20:30 [PATCH] pata_hpt3x2n: fix timing register masks (take 2) Sergei Shtylyov
2009-12-04 22:29 ` Sergei Shtylyov
2009-12-04 23:29 ` Alan Cox
2009-12-04 23:34 ` Sergei Shtylyov [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=4B199C95.7080708@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--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.