On Thu, Nov 18, 2010 at 11:01:33AM +0100, Sascha Hauer wrote: > On Thu, Nov 18, 2010 at 10:36:51AM +0100, Belisko Marek wrote: > > Hi, > > > > On Wed, Nov 17, 2010 at 10:11 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > > Hi Marek, > > > > > > On Mon, Nov 15, 2010 at 03:20:47PM +0100, Belisko Marek wrote: > > >> Hi, > > >> > > >> barebox compilation with C=1 produce a lot of sparse warnings. > > >> Mainly concerning __iomem problems with readb() and similar functions. > > >> > > >> Make it sense to take care or just could be omitted? > > > > > > I think it makes sense to work on this. Then we can see the useful > > > warnings buried under the __iomem warnings. > > > > > > I had the idea of adding a > > > > > > #define IOMEM(addr) ((void __force __iomem *)(addr)) > > > > > > and use it where appropriate. > > Maybe stupid question but couldn't be __iomem mechanism removed completely? > > Do we need to check for different address_space? In my opinion it > > makes no sense in > > barebox. > > I have a better feeling letting it in. There may be no different address > spaces on Arm, but there are for exmample on x86. > You can simply do a #define __iomem in include/linux/compiler.h to > silence these kinds of warnings temporarily if you are not interested. > I agree that at least on Arm these warnings will not reveal any real > bugs. I can imagine you to get hard to find bugs if you interpret a pointer to registers as normal pointer without volatile. Something like: unsigned long *register = 0xabcdef04; while (*register & SOME_FLAG) /* nothing */ This might generate code that corresponds to if (*register & SOME_FLAG) while(1); So I feel for letting it in, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
