On Thu, Feb 14, 2013 at 08:47:53PM +0000, Paul Walmsley wrote:
> Regarding ioremap(), it seems reasonable for drivers to call ioremap(), as
> long as the implementation of ioremap() can be overridden by the device's
> bus. PCI device drivers already do this -- albeit in a PCI-specific way
> -- with pci_ioremap_bar():
Err no, that's just a helper to assist checking the resource type and
remove all those pesky resource size mistakes - see the commit text:
PCI: introduce an pci_ioremap(pdev, barnr) function
A common thing in many PCI drivers is to ioremap() an entire bar. This
is a slightly fragile thing right now, needing both an address and a
size, and many driver writers do.. various things there.
This patch introduces an pci_ioremap() function taking just a PCI device
struct and the bar number as arguments, and figures this all out itself,
in one place. In addition, we can add various sanity checks to this
function (the patch already checks to make sure that the bar in question
really is a MEM bar; few to no drivers do that sort of thing).
Hopefully with this type of API we get less chance of mistakes in
drivers with ioremap() operations.
Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>
> So instead of something bus-specific like that, a better way would be to
> use something like:
>
> va = dev->bus->ioremap( ... );
> va = dev->bus->iounmap( ... );
No. ioremap() is already generic. We don't need additional layers of
indirection per bus type.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
