From: Paul Mundt <lethal@linux-sh.org>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ata: pata_platform: Disable prereset logic.
Date: Wed, 23 May 2007 17:30:26 +0900 [thread overview]
Message-ID: <20070523083026.GA29851@linux-sh.org> (raw)
In-Reply-To: <4653F62C.4070700@gmail.com>
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
> Paul Mundt wrote:
> > On a number of boards the current prereset logic seems to misbehave:
> >
> > scsi0 : pata_platform
> > ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x00000000 irq 0
> > ata1: device not ready (errno=-19), forcing hardreset
> > ata1: BUG: prereset() requested invalid reset type
> >
> > This triggers when there is no card inserted in the slot.
> >
> > Simply disabling the prereset gets rid of this, and doesn't seem to cause
> > any problems for either PCMCIA or CF cards when they're actually present.
>
> NACK. The BUG printking needs fixing but you can't just kill
> prereset(). Did it work properly on 2.6.21.1? Can you modify
> ata_wait_ready() such that it prints out the status value while waiting?
>
ata_wait_ready() works fine, it reports 0xff immediately (and this is
what I would expect when there is no card inserted).
The board that exhibits this behaviour wasn't supported in the older
kernels, I can backport and test if it will be useful, though.
next prev parent reply other threads:[~2007-05-23 8:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-23 6:44 [PATCH] ata: pata_platform: Disable prereset logic Paul Mundt
2007-05-23 8:07 ` Tejun Heo
2007-05-23 8:30 ` Paul Mundt [this message]
2007-05-23 9:29 ` Tejun Heo
2007-05-23 9:48 ` Paul Mundt
2007-05-23 9:58 ` [PATCH] libata: -ENODEV during prereset isn't an error 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=20070523083026.GA29851@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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 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.