[PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

Russell King - ARM Linux linux at arm.linux.org.uk
Sat Oct 9 10:37:09 EDT 2010

On Sat, Oct 09, 2010 at 03:10:57PM +0300, Felipe Contreras wrote:
> On Sat, Oct 9, 2010 at 2:43 PM, Dave Airlie <airlied at gmail.com> wrote:
> >> The few drivers that may be hit by this are typically in drivers/staging
> >> exactly because issues like this have not been fixed yet.
> >>
> >> We should probably just fix the non-staging drivers that are hit by
> >> this now and declare the issue done.
> >>
> >> When you say that "many drivers broken", can you list the ones you know
> >> about? It would probably help resolve this the right way.
> >
> > I'm guessing some closed source graphics drivers for ARM do all kinds
> > of wrong crap, and Nokia use them a lot, and nobody wants to tell the
> > closed vendors to change their drivers because it costs money.
> You are over simplifying things.
>  1) The code is open[1]
>  2) the decision comes from TI, Nokia can only do so much before shipping

Well -

1. TI had been complaining last December about vmalloc() creating mappings
   with different shared-ness attributes causing problems with OMAP.

2. May 10, TI on the three-weekly conference call were warned about this
   change to ioremap with system RAM - and this was noted in the minutes
   and circulated.  It was brought up again on June 21st, and yet again
   on August 2nd.

So, the major players in the OMAP community were repeatedly made plainly
aware of this change and some were aware of the problems caused by
violating these kinds of restrictions.

You tell me - if I've raised the issue on the mailing list to which OMAP
people are aware of (and note that there was a reply from OMAP folk in
the inital thread), if I've raised it several times with TI in conference
calls which include the major players, and still OMAP drivers are doing
things wrongly.

You can lead the horse to water but you can not make it drink.  At some
point it either drinks or dies.  In this case, it seems death is the
favoured option as the warnings have been repeatedly ignored.

More information about the linux-arm-kernel mailing list