From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <htejun@gmail.com>,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] libata: always use polling SETXFER
Date: Sun, 3 Jun 2007 19:24:46 +0200 [thread overview]
Message-ID: <200706031924.46238.bzolnier@gmail.com> (raw)
In-Reply-To: <4662E5B3.4020205@garzik.org>
Hi,
On Sunday 03 June 2007, Jeff Garzik wrote:
> Tejun Heo wrote:
> > Several people have reported LITE-ON LTR-48246S detection failed
> > because SETXFER fails. It seems the device raises IRQ too early after
> > SETXFER. This is controller independent. The same problem has been
> > reported for different controllers.
> >
> > So, now we have pata_via where the controller raises IRQ before it's
> > ready after SETXFER and a device which does similar thing. This patch
> > makes libata always execute SETXFER via polling. As this only happens
> > during EH, performance impact is nil. Setting ATA_TFLAG_POLLING is
> > also moved from issue hot path to ata_dev_set_xfermode() - the only
> > place where SETXFER can be issued.
> >
> > Note that ATA_TFLAG_POLLING applies only to drivers which implement
> > SFF TF interface and use libata HSM. More advanced controllers ignore
> > the flag. This doesn't matter for this fix as SFF TF controllers are
> > the problematic ones.
> >
> > Signed-off-by: Tejun Heo <htejun@gmail.com>
> > ---
> > drivers/ata/libata-core.c | 13 ++++---------
> > drivers/ata/pata_via.c | 12 ++++++------
> > include/linux/libata.h | 1 -
> > 3 files changed, 10 insertions(+), 16 deletions(-)
>
> To Linus and Andrew:
>
> After discussion and a minor revision (mostly to the description), I am
> OK with this patch.
>
> At this point, I am only reluctant to push it for 2.6.22 since it is so
> late in the -rc series.
>
> If we have another -rc, I would probably be OK with pushing it for
> 2.6.22, otherwise I would prefer to wait for 2.6.23.
>
> Comments solicited, from all involved...
I have a feeling that we are needlessly wasting time on this.
The patch should be safe (drivers/ide has been doing SETXFER this way for
ages) and fixes real user problems (which becomes even more important now as
distros are converting to libata PATA).
So.. can we get this almost 3 months old patch merged finally?
http://thread.gmane.org/gmane.linux.ide/17096/focus=17116
Thanks,
Bart
next prev parent reply other threads:[~2007-06-03 17:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-27 13:10 [PATCH] libata: always use polling SETXFER Tejun Heo
2007-06-03 16:00 ` Jeff Garzik
2007-06-03 17:24 ` Bartlomiej Zolnierkiewicz [this message]
2007-06-03 18:45 ` Linus Torvalds
2007-06-03 18:17 ` Andrew Morton
2007-06-03 19:40 ` Linus Torvalds
2007-06-04 14:42 ` Alan Cox
2007-06-04 20:34 ` Linus Torvalds
2007-06-04 20:38 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2007-03-14 5:33 Tejun Heo
2007-03-14 14:09 ` Bartlomiej Zolnierkiewicz
2007-04-30 0:45 ` Tejun Heo
2007-05-25 10:58 ` Jeff Garzik
2007-05-25 11:58 ` Tejun Heo
2007-05-25 12:26 ` Jeff Garzik
2007-05-25 12:52 ` 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=200706031924.46238.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=htejun@gmail.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=torvalds@linux-foundation.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).