[RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
Russell King - ARM Linux
linux at arm.linux.org.uk
Fri Feb 15 05:26:09 EST 2013
On Thu, Feb 14, 2013 at 09:40:29PM +0000, Paul Walmsley wrote:
> Hi,
>
> On Thu, 14 Feb 2013, Paul Walmsley wrote:
>
> > 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( ... );
>
> Something like this is what I was thinking. Obviously there would be more
> patches needed, for the various arches, etc.; and I'm not convinced that
> the function pointer init is done at the right time yet. Comments welcome.
Not only does this break the "ioremap caller" stuff, allowing the caller
of ioremap() to be recorded, I believe this to be a total abonimation.
> This might also be useful as a generic replacement for pci_ioremap_bar().
No it isn't. Read the comments about why pci_ioremap_bar() was introduced
in its original commit. It's there to reduce the number of common errors
with mapping a PCI bar, so it takes the PCI device and the BAR index.
It has a totally different interface to standard ioremap(). It can't be
twisted into the standard ioremap() interface in any shape or form.
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index ce328c7..303dba0 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -17,6 +17,7 @@
> #include <linux/fs.h>
> #include <linux/vmalloc.h>
> #include <linux/sizes.h>
> +#include <linux/platform_device.h>
>
> #include <asm/cp15.h>
> #include <asm/cputype.h>
> @@ -28,6 +29,7 @@
> #include <asm/highmem.h>
> #include <asm/system_info.h>
> #include <asm/traps.h>
> +#include <asm/io.h>
How many more bloody times do I have to tell people about using asm/io.h
directly? You've been around for _long_ enough that you well know this
by now. There is no excuse for this kind of thing other than shere
laziness or down-right sloppyness on your part.
If I make a big enough thing about it, hopefully people will become scared
to post their un-self-reviewed patches and instead start taking a little
more care in future.
More information about the linux-arm-kernel
mailing list