[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