From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754885AbcBHUDU (ORCPT ); Mon, 8 Feb 2016 15:03:20 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:56741 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753286AbcBHUDS (ORCPT ); Mon, 8 Feb 2016 15:03:18 -0500 Date: Mon, 8 Feb 2016 12:03:17 -0800 From: Andrew Morton To: Brian Starkey Cc: Greg Kroah-Hartman , Catalin Marinas , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag Message-Id: <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org> In-Reply-To: <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com> References: <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Feb 2016 17:30:50 +0000 Brian Starkey wrote: > Add a flag to memremap() for writecombine mappings. Mappings satisfied > by this flag will not be cached, however writes may be delayed or > combined into more efficient bursts. This is most suitable for > buffers written sequentially by the CPU for use by other DMA devices. > > ... The patch generally looks OK to me. It generates rejects against linux-next because of some janitorial changes in memremap.c. > @@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags) > addr = ioremap_wt(offset, size); > } > > + if (!addr && (flags & MEMREMAP_WC)) { > + flags &= ~MEMREMAP_WC; > + addr = ioremap_wc(offset, size); > + } > + > return addr; > } The modifications of `flags' is unneeded (and the compiler will remove it). And generally the modification of incoming args is a bit nasty IMO - I find it's better to treat them as const - part of the calling environment which can be relied upon to be unaltered as the code evolves.