On 23 February 2016 at 23:23, Robert Jarzmik wrote:
> Dan Williams writes:
>
>> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
>> wrote:
>>> On 23 February 2016 at 13:03, Ard Biesheuvel
On 23 February 2016 at 23:23, Robert Jarzmik wrote:
> Dan Williams writes:
>
>> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
>> wrote:
>>> On 23 February 2016 at 13:03, Ard Biesheuvel
>>> wrote:
On 23 February 2016 at 12:58, Russell King - ARM Linux
wrote:
> On Mon, Feb 22,
Dan Williams writes:
> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
> wrote:
>> On 23 February 2016 at 13:03, Ard Biesheuvel
>> wrote:
>>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>>>
Dan Williams writes:
> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
> wrote:
>> On 23 February 2016 at 13:03, Ard Biesheuvel
>> wrote:
>>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>>> wrote:
On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>> OK, I see
On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
wrote:
> On 23 February 2016 at 13:03, Ard Biesheuvel
> wrote:
>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>> wrote:
>>> On Mon, Feb 22, 2016 at
On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
wrote:
> On 23 February 2016 at 13:03, Ard Biesheuvel
> wrote:
>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>> wrote:
>>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
OK, thanks for the historical context.
On 23 February 2016 at 13:03, Ard Biesheuvel wrote:
> On 23 February 2016 at 12:58, Russell King - ARM Linux
> wrote:
>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>>> OK, thanks for the historical context.
>>>
>>> So what
On 23 February 2016 at 13:03, Ard Biesheuvel wrote:
> On 23 February 2016 at 12:58, Russell King - ARM Linux
> wrote:
>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>>> OK, thanks for the historical context.
>>>
>>> So what is your opinion on this series, i.e., to wire up
On 23 February 2016 at 12:58, Russell King - ARM Linux
wrote:
> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>> OK, thanks for the historical context.
>>
>> So what is your opinion on this series, i.e., to wire up memremap() to
>> remap arbitrary memory
On 23 February 2016 at 12:58, Russell King - ARM Linux
wrote:
> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>> OK, thanks for the historical context.
>>
>> So what is your opinion on this series, i.e., to wire up memremap() to
>> remap arbitrary memory regions into the vmalloc
On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
> OK, thanks for the historical context.
>
> So what is your opinion on this series, i.e., to wire up memremap() to
> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
> attributes, and at the same time lift the
On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
> OK, thanks for the historical context.
>
> So what is your opinion on this series, i.e., to wire up memremap() to
> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
> attributes, and at the same time lift the
On 22 February 2016 at 21:02, Russell King - ARM Linux
wrote:
> On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
>> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
>> attributes, but the ARM architecture simply does not allow mismatched
On 22 February 2016 at 21:02, Russell King - ARM Linux
wrote:
> On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
>> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
>> attributes, but the ARM architecture simply does not allow mismatched
>> attributes, so we
On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
On Mon, Feb 22, 2016 at 11:17 AM, Ard Biesheuvel
wrote:
> On 22 February 2016 at 20:05, Dan Williams wrote:
>> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
>> wrote:
>>> Currently, the memremap code serves
On Mon, Feb 22, 2016 at 11:17 AM, Ard Biesheuvel
wrote:
> On 22 February 2016 at 20:05, Dan Williams wrote:
>> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
>> wrote:
>>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>>> the kernel direct mapping, unless the region is
On 22 February 2016 at 20:05, Dan Williams wrote:
> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
> wrote:
>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>> the kernel direct mapping, unless the region is in high
On 22 February 2016 at 20:05, Dan Williams wrote:
> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
> wrote:
>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>> the kernel direct mapping, unless the region is in high memory, in which
>> case it falls back to using
On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
wrote:
> Currently, the memremap code serves MEMREMAP_WB mappings directly from
> the kernel direct mapping, unless the region is in high memory, in which
> case it falls back to using ioremap_cache(). However, the
On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
wrote:
> Currently, the memremap code serves MEMREMAP_WB mappings directly from
> the kernel direct mapping, unless the region is in high memory, in which
> case it falls back to using ioremap_cache(). However, the semantics of
> ioremap_cache() are
Currently, the memremap code serves MEMREMAP_WB mappings directly from
the kernel direct mapping, unless the region is in high memory, in which
case it falls back to using ioremap_cache(). However, the semantics of
ioremap_cache() are not unambiguously defined, and on ARM, it will
actually result
Currently, the memremap code serves MEMREMAP_WB mappings directly from
the kernel direct mapping, unless the region is in high memory, in which
case it falls back to using ioremap_cache(). However, the semantics of
ioremap_cache() are not unambiguously defined, and on ARM, it will
actually result
24 matches
Mail list logo