On Wed, 17 Feb 2016 11:53:48 + Brian Starkey wrote:
> Hi Andrew,
>
> Would you pick these up if I rebase onto linux-next?
Sure.
> How strongly do you feel about the input argument modification vs.
> staying in-line with the rest of the function?
I see no reason why memremap() is modifying
Hi Andrew,
Would you pick these up if I rebase onto linux-next?
How strongly do you feel about the input argument modification vs.
staying in-line with the rest of the function?
Thanks,
Brian
On Tue, Feb 09, 2016 at 10:23:00AM +, Brian Starkey wrote:
Hi Andrew,
Thanks for taking a look,
On Tue, Feb 16, 2016 at 04:43:51PM -0800, Greg Kroah-Hartman wrote:
On Tue, Feb 16, 2016 at 11:14:26AM +, Brian Starkey wrote:
Hi Greg,
Is the documentation OK? Is there any chance of you picking up this
series?
I can rebase onto -next if that's the right place, but they still apply
on 4.5
On Tue, Feb 16, 2016 at 11:14:26AM +, Brian Starkey wrote:
> Hi Greg,
>
> Is the documentation OK? Is there any chance of you picking up this
> series?
>
> I can rebase onto -next if that's the right place, but they still apply
> on 4.5-rc4 and fix a panic, so I thought perhaps they could mak
Hi Greg,
Is the documentation OK? Is there any chance of you picking up this
series?
I can rebase onto -next if that's the right place, but they still apply
on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.
Thanks,
Brian
On Tue, Feb 09, 2016 at 09:15:02AM +, Brian Stark
Hi Andrew,
Thanks for taking a look,
On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
On Mon, 8 Feb 2016 17:30:50 + Brian Starkey wrote:
The patch generally looks OK to me. It generates rejects against
linux-next because of some janitorial changes in memremap.c.
Ah yeah,
Hi Greg,
On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
On Mon, Feb 08, 2016 at 05:30:50PM +, Brian Starkey wrote:
diff --git a/include/linux/io.h b/include/linux/io.h
index 32403b5..e2c8419 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -135,6 +135,7 @@ enum {
On Mon, 8 Feb 2016 17:30:50 + 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 t
On Mon, Feb 08, 2016 at 05:30:50PM +, 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
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.
Signed-off-by: Brian Starkey
10 matches
Mail list logo
