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