mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [RFC] pata_icside driver
Date: Sun, 8 Apr 2007 19:59:56 +0100	[thread overview]
Message-ID: <20070408195956.4e7d50c0@the-village.bc.nu> (raw)
In-Reply-To: <20070408101826.GA5431@flint.arm.linux.org.uk>

> The second FIXME area is ata_irq_ack - it is unconditionally coded
> for SFF-type interfaces.  I believe that using this function in
> non-BMDMA interfaces is wrong - it attempts to read from the BMDMA
> registers irrespective of whether ap->ioaddr.bmdma_addr is set or
> not.  The question this poses is: what should non-BMDMA implementations
> use for this method?  Note that pata_platform also uses this
> function despite not supporting BMDMA which seems even more suspicious.

Thats a bug that has arrived again. The older code was corrected to
handle this properly but the fix appears to have become lost. The
ioread/iowrite code actually made quite a mess (all the address reporting
is also broken) and we do some iffy things like compare the iomap result
with zero and assume thats the same as checking for true bus zero
addresses.

ata_irq_ack is part of the SFF layer so its fine that it assumes SFF but
its wrong that it is used unconditionally and it shouldn't be used this
way. It just needs a (!ap->ioaddr.bmdma_addr) test adding (assuming thats
valid for iomap)


Alan

  reply	other threads:[~2007-04-08 18:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30 11:00 [PATCH] Provide dummy devm_ioport_* if !HAS_IOPORT Russell King
2007-03-30 11:08 ` [RFC] pata_platform for ARM RiscPC Russell King
2007-04-08 10:18   ` [RFC] pata_icside driver Russell King
2007-04-08 18:59     ` Alan Cox [this message]
2007-04-09  1:03       ` Jeff Garzik
2007-04-09  9:56         ` Alan Cox
2007-04-09 10:56           ` Jeff Garzik
2007-04-09 11:13             ` Jeff Garzik
2007-04-09 11:36               ` Russell King
2007-04-09 12:02                 ` Jeff Garzik
2007-04-08 20:09     ` Alan Cox
2007-04-09  8:18       ` Russell King
2007-04-09  8:24         ` Roland Dreier
2007-04-09  8:44           ` Russell King
2007-04-09 10:25         ` Alan Cox
2007-04-09 11:33           ` Russell King
2007-04-21 15:09     ` Russell King
2007-04-09 11:32   ` [RFC] pata_platform for ARM RiscPC Jeff Garzik
2007-03-30 11:08 ` [PATCH] Provide dummy devm_ioport_* if !HAS_IOPORT Christoph Hellwig

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=20070408195956.4e7d50c0@the-village.bc.nu \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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

all inboxes | Powered by JetHome®