All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	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: Mon, 29 Jan 2007 10:01:23 +1100	[thread overview]
Message-ID: <1170025283.26655.101.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0701251751380.25027@woody.linux-foundation.org>

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

Well, as I said, I prefer keeping PIO numbers 0 based so that legacy
crap works. If 0 is to be illegal, then remap any devive that's sitting
there, but don't do weirder remapping tricks than necessary ;-) 

Note that on PowerPC, we do actually remap PIO on non-primary busses
(well, we have to since we have to present a flat space to inx/outx).

What we do there is basically we "pick" a bus as beeing primary
(typically the one that has an ISA bridge and/or SuperIO on it) and
that's the one that gets PIO 0. Resources for device on that domain
aren't fixed up.

All other ones are fixed up in such a way that pointer arithmeric gives
you an inx/outx landing in the right spot for PCI devices.

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

Yes. Though adoption of iomap is a bit slow on the driver side of
things.

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

Well, hopefully new drivers don't need PIO as it's about time people
stop releasing devices that do PIO, bloody hell ! That should have been
"deprecated use for compatibility only" from day #1 :-) In fact, if I'm
not mistaken, the PCI spec mandates that device should have an MMIO way
of doing everything that can be done via PIO nowadays no ?

Ben.



  parent reply	other threads:[~2007-01-28 23:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 15:09 [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable controllers 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
2007-01-26  2:11               ` Jeff Garzik
2007-01-26 10:37               ` Alan
2007-01-28 23:01               ` Benjamin Herrenschmidt [this message]
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=1170025283.26655.101.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dwmw2@infradead.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@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 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.