On Tue, Oct 26, 2010 at 07:43:07AM +0100, Ben Dooks wrote: > On Tue, Oct 26, 2010 at 01:02:03PM +0900, Paul Mundt wrote: > > On Tue, Oct 26, 2010 at 09:08:12AM +0900, Nobuhiro Iwamatsu wrote: > > > 2010/10/25 Ben Dooks <ben-i2c@xxxxxxxxx>: > > > > On Mon, Oct 25, 2010 at 08:13:25PM +0900, Paul Mundt wrote: > > > >> On Mon, Oct 25, 2010 at 11:47:18AM +0100, Ben Dooks wrote: > > > >> > On Mon, Oct 25, 2010 at 10:58:35AM +0900, Paul Mundt wrote: > > > >> > > On Sat, Oct 23, 2010 at 07:07:00AM +0900, Nobuhiro Iwamatsu wrote: > > > >> > > > ctrl_* is deprecated. We should to use __raw_*. > > > >> > > > > > > >> > > > Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@xxxxxxxxxxx> > > > >> > > > > > >> > > Applied, thanks. > > > >> > > > > >> > Hi, can you see my comments about the copy of this posted below > > > >> > about ioremap() and use or __raw accessors? > > > >> > > > > >> No? At least it never made it to the list. Do you have a pointer handy? > > > > > > > > http://marc.info/?l=linux-i2c&m=128797023230600&w=2 > > > > > > > > > > Sorry, this is my mistake. > > > > > > >> On Sun, Oct 24, 2010 at 05:37:46PM +0900, Nobuhiro Iwamatsu wrote: > > > >> ctrl_* is deprecated. We should to use __raw_*. > > > > > > > >> Given iobase is ioremap() returned, there should be an explicit reason > > > >> for using __raw_xxx() instead of read/writel(). > > > > > Based on what, exactly? The CPU in question is quite content with the > > weak ordering provided by __raw_xxx(), anything more is unecessary. > > generally, readX,writeX or iowriteX,ioreadX are the functions that should > be used on ioremap()d memory. It may not be a hard rule, but it is how it > is supposed to be done. > Nonsense. There are plenty of cases in the kernel that use __raw_xxx() on ioremapped memory and have been since before ioread/writeX even existed. Whether to use read/writeX or the __raw versions has always been up to the developer, and if the ordering issues don't factor in then there is simply no reason to bother using read/writeX. If you wish to do a kernel-wide audit and convert all __raw_xxx users on ioremapped memory over you are certainly welcome to try. Inserting extra memory barriers for strong ordering where it isn't needed however is completely pointless. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html