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
9 matches
Mail list logo
