linux/pgtable.h has been included at line 11 with annotation.
So we remove the duplicate one at line 8.
Signed-off-by: Wan Jiabing
---
include/linux/crash_dump.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index a5192b718dbe..be79a45
On 2021-03-22, Petr Mladek wrote:
> On Mon 2021-03-22 12:16:15, John Ogness wrote:
>> On 2021-03-21, Sergey Senozhatsky wrote:
>> >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt,
>> >> va_list args)
>> >>* Use the main logbuf even in NMI. But avoid calling console
>> >
On Mon 2021-03-22 12:16:15, John Ogness wrote:
> On 2021-03-21, Sergey Senozhatsky wrote:
> >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt,
> >> va_list args)
> >> * Use the main logbuf even in NMI. But avoid calling console
> >> * drivers that might have their own
On Wed, Mar 17, 2021 at 5:31 AM Geert Uytterhoeven
wrote:
>
> Parse the following DT properties in the crash dump kernel, to provide a
> modern interface between kexec and the crash dump kernel:
> - linux,elfcorehdr: ELF core header segment, similar to the
> "elfcorehdr=" kernel parameter.
>
On Mon, Mar 22, 2021 at 9:02 AM David Hildenbrand wrote:
>
> It used to be true that we can have busy system RAM only on the first level
> in the resourc tree. However, this is no longer holds for driver-managed
> system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on
> lower le
On Mon, Mar 22, 2021 at 9:03 AM David Hildenbrand wrote:
>
> All IORESOURCE_SYSTEM_RAM and IORESOURCE_MEM now properly consider the
> whole resource tree, not just the first level. Let's drop the unused
> first_lvl / siblings_only logic.
>
> All functions properly search the whole tree, so remove
On Mon, Mar 22, 2021 at 9:02 AM David Hildenbrand wrote:
>
> It used to be true that we can have system RAM only on the first level
> in the resourc tree. However, this is no longer holds for driver-managed
> system RAM (i.e., dax/kmem and virtio-mem).
>
> The function walk_mem_res() only consider
It used to be true that we can have system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., dax/kmem and virtio-mem).
The function walk_mem_res() only consideres the first level and is
used in arch/x86/mm/ioremap.c:__ioremap_che
All IORESOURCE_SYSTEM_RAM and IORESOURCE_MEM now properly consider the
whole resource tree, not just the first level. Let's drop the unused
first_lvl / siblings_only logic.
All functions properly search the whole tree, so remove documentation
that indicates that some functions behave differently.
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on
lower levels.
We have two users of walk_system_ram_res(), which currently o
On 2021-03-21, Sergey Senozhatsky wrote:
>> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list
>> args)
>> * Use the main logbuf even in NMI. But avoid calling console
>> * drivers that might have their own locks.
>> */
>> -if ((this_cpu_read(printk
11 matches
Mail list logo
