[PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
Felipe Contreras
felipe.contreras at gmail.com
Sat Oct 9 07:59:45 EDT 2010
2010/10/9 Arnd Bergmann <arnd at arndb.de>:
> On Saturday 09 October 2010 12:28:19 Felipe Contreras wrote:
>> Also, what do you think is the right attitude? Do you think all
>> driver writers should follow each and every patch on the mailing list
>> or always try release candidates? Even if they all did (some do),
>> there's no generic solution, so they all are scratching their heads
>> about how to solve this. It might be crystal clear for you how such
>> generic solution could be implemented, or perhaps how some of these
>> drivers can be fixed individually, if so, why don't you come with a
>> proposal to mitigate the pain of fixing such drivers.
>
> Please put this into perspective, it's not like this was ever a
> normal thing to do, and drivers doing an ioremap on kernel memory
> would typically not make it through a review. I've looked through
> the ARM specific drivers that do ioremap and practically all of
> them just map their MMIO registers as they should.
>
> 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 know of tidspbridge, in my original mail I listed some links, one
which mentions: sh_mobile_ceu_camera, maybe i.MX31 users of the
mx3_camera driver: pcm037 and mx31moboard.
http://article.gmane.org/gmane.linux.ports.sh.devel/8560
More information about the linux-arm-kernel
mailing list