LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Alan <alan@lxorguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers
Date: Thu, 25 Jan 2007 18:01:43 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701251751380.25027@woody.linux-foundation.org> (raw)
In-Reply-To: <45B95D3A.10108@pobox.com>



On Thu, 25 Jan 2007, Jeff Garzik wrote:
> 
> On sparc64, for example, after I pointed this out to DaveM, he was able to
> implement the new iomap interface without the 'if (pio-mem-area)' branch
> present on x86.

However, in all honesty, we have triggered bugs in that area too, simply 
because some driver code "knew" that PIO addresses could fit in 16 bits, 
and used u16 or "unsigned short" to remember the PIO address. Both ARM and 
Sparc was bitten by this, although usually the issue is trivial to fix 
once found.

Also, many ISA-only drivers actually have hardcoded PIO numbers (eg 
"0x1f0").

But yes, I would generally suggest that architectures where the PIO range 
is really just another magic MMIO range (which is most of the non-x86 
world, as you point out) might as well at least aim for doing the 
remapping early (ie with "pci_resource_start()")

Making that easy was one of my goals for the "new" IO accessor functions, 
in fact.

Not that many people actually use them.

So *if* you use the new "iomap" interfaces, and the new "pci_iomap()" 
things, that should actually not just allow drivers (like the ATA layer) 
to share much more code between the PIO and MMIO cases, but it hopefully 
actually makes it easier for strange architectures to do it all.

So traditionally, we've had PIO be "limited integer addresses, and some 
drivers know magic numbers", but hopefully new drivers could at least try 
to use some of the infrastructure where we try to help people not have to 
deal with it so much as a special case any more.

			Linus

  reply	other threads:[~2007-01-26  2:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 15:09 Alan
2007-01-25 16:14 ` David Woodhouse
2007-01-25 16:17   ` Jeff Garzik
2007-01-25 16:19     ` David Woodhouse
2007-01-25 16:22     ` Russell King
2007-01-25 16:26       ` David Woodhouse
2007-01-25 17:27   ` Alan
2007-01-25 17:56     ` Linus Torvalds
2007-01-26  0:23       ` David Woodhouse
2007-01-26  1:28         ` Linus Torvalds
2007-01-26  1:45           ` Jeff Garzik
2007-01-26  2:01             ` Linus Torvalds [this message]
2007-01-26  2:11               ` Jeff Garzik
2007-01-26 10:37               ` Alan
2007-01-28 23:01               ` Benjamin Herrenschmidt
2007-01-28 22:57             ` Benjamin Herrenschmidt
2007-01-26  2:23           ` David Woodhouse
2007-01-26  2:58             ` Linus Torvalds
2007-01-26  3:28               ` David Woodhouse
2007-01-26  4:00                 ` Linus Torvalds
2007-01-26  4:19                   ` David Woodhouse
2007-01-26  4:48                     ` Linus Torvalds
2007-01-26  5:09                       ` David Woodhouse
2007-01-26  6:01                         ` Linus Torvalds
2007-01-26  6:18                           ` Linus Torvalds
2007-01-26  8:17                             ` David Miller
2007-01-26  8:20                         ` David Miller
2007-01-26  4:53                 ` Jeff Garzik
2007-01-26 15:32                 ` Mark Lord
2007-01-26 15:29               ` Mark Lord
2007-01-28 23:04               ` Benjamin Herrenschmidt
2007-01-28 22:49       ` Benjamin Herrenschmidt
2007-01-25 23:36 ` Jeff Garzik

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=Pine.LNX.4.64.0701251751380.25027@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dwmw2@infradead.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH] libata-sff: Don'\''t call bmdma_stop on non DMA capable controllers' \
    /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

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).