Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capablecontrollers

[Benjamin Herrenschmidt]

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/