[RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Russell King - ARM Linux]

On Tue, Feb 19, 2013 at 03:30:01PM +0000, Paul Walmsley wrote:
> Hi,
> 
> On Thu, 14 Feb 2013, Tony Lindgren wrote:
> 
> > The other option could be to allow custom ioremap function pointers 
> > based on address range in __arm_ioremap_pfn_caller() the same way as
> > the SoC specific static mappings are allowed. That would require adding
> > a function pointer to struct map_desc.
> > 
> > Maybe that would do the trick?
> 
> That sounds fine to me too.
> 
> To me it makes sense to eventually handle the I/O mappings automatically 
> from data in the DT -- hence the association with a bus device, which 
> should be present in DT data.

No.  I really don't get why OMAP thinks it's soo special that it needs
to go around adding lots and lots of new abstractions all over the
place.

Indirect ioremap() through a function pointer so you can overload it with
OMAP specific crap?  No way.  Function pointers in map_desc - what the hell
for?

You must be totally mad if you think that's a way forward, I really don't
see how you think this kind of crap would be remotely acceptable.

Ok, so you have this problem that you need hwmod to touch a register which
is also contained within the device resources as well.  That's fine.  You
can do it one of two ways:

1. Call out from the driver at the appropriate points (which seems to be
   _after_ you've ioremapped it) to access the register.

2. Find the resource, temporarily map the register, access it, and then
   unmap it.

No requirement what so ever to override ioremap().  AT ALL.  So stop this
madness now.

As for a function pointer in struct map_desc.  You're bonkers, the lot of
you.  map_desc is a structure describing the boot time static mappings
which gets discarded.  Nothing keeps any references around to it, and it
is used at a time when *NOTHING ELSE* should be going on in the kernel
other than building those static mappings.  Not even any arch code poking
about at devices.  Or anything like that.  Because if you think that's
acceptable, then we'll need to flush the cache and TLB after each and
every map_desc entry is touched - which brings a whole load of new pain
and slowness to the kernel boot.

So please, stop this idiotic madness now.

If you want such things as pci_enable_device(), then what you're actually
asking for is omap_enable_device() for OMAP devices.  OMAP devices are
already specific enough to OMAP SoCs (god knows, they have really complex
and obscure behaviours that no one else in their right mind would want
to copy) that calling out to omap specific functions would never really
be a problem.

No need for any of this crazy dev->bus shit either.