[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201106071322.29884.arnd@arndb.de>
Date: Tue, 7 Jun 2011 13:22:29 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: linux-m68k@...ts.linux-m68k.org,
Akinobu Mita <akinobu.mita@...il.com>,
linux-kernel@...r.kernel.org, Ben Hutchings <ben@...adent.org.uk>,
linux-ide@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tuesday 07 June 2011, Geert Uytterhoeven wrote:
> You mean the host_busy variable in the IDE code?
> That would also apply to context_flag in the DRM code:
>
> drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
> ‘__constant_test_and_set_bit’ discards qualifiers from pointer target
> type
> drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
> ‘__generic_test_and_set_bit’ discards qualifiers from pointer target
> type
Yes, that fits the same category.
> > is wrong, though. It probably doesn't hurt to do both.
>
> asm-generic/bitops/atomic.h has the volatiles everywhere. That's why
> I'm wondering.
I guess what happened is that some variables are traditionally marked
as volatile although they shouldn't be, and most architectures have
adapted their bitops to make the warnings go away. If you see more
warnings of that kind, it's probably fine to just do the same on m68k.
The volatile modifier doesn't really hurt in this case.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists