Linux M68K

• Thread Index

• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
  • From: Vishal Moola <vishal.moola@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH 4/33] mm: add utility functions for ptdesc
  • From: Vishal Moola <vishal.moola@xxxxxxxxx>
• Re: [PATCH v3 00/19] arch: Consolidate <asm/fb.h>
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 4/33] mm: add utility functions for ptdesc
  • From: Vernon Yang <vernon2gm@xxxxxxxxx>
• Re: reliable reproducer, was Re: core dump analysis
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Justin Forbes <jforbes@xxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• reliable reproducer, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v3 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
  • From: Vishal Moola <vishal.moola@xxxxxxxxx>
• Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH v3 00/19] arch: Consolidate <asm/fb.h>
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH 12/33] mm: Create ptdesc equivalents for pgtable_{pte,pmd}_page_{ctor,dtor}
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 04/33] mm: add utility functions for ptdesc
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 94ea4c5cbeeba22abb2abca416eedb2aca30bc67
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH 24/33] m68k: Convert various functions to use ptdescs
  • From: kernel test robot <lkp@xxxxxxxxx>
• [PATCH 30/33] sparc64: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 33/33] mm: Remove pgtable_{pmd, pte}_page_{ctor, dtor}() wrappers
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 28/33] riscv: Convert alloc_{pmd, pte}_late() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 31/33] sparc: Convert pgtable_pte_page_{ctor, dtor}() to ptdesc equivalents
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 29/33] sh: Convert pte_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 32/33] um: Convert {pmd, pte}_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 27/33] openrisc: Convert __pte_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 26/33] nios2: Convert __pte_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 25/33] mips: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 24/33] m68k: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 20/33] arm64: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 14/33] x86: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 23/33] loongarch: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 07/33] mm: Convert ptlock_ptr() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 17/33] mm: Remove page table members from struct page
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 21/33] csky: Convert __pte_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 15/33] s390: Convert various gmap functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 13/33] powerpc: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 08/33] mm: Convert pmd_ptlock_init() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 05/33] mm: Convert pmd_pgtable_page() to pmd_ptdesc()
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 18/33] pgalloc: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 11/33] mm: Convert ptlock_free() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 16/33] s390: Convert various pgalloc functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 12/33] mm: Create ptdesc equivalents for pgtable_{pte,pmd}_page_{ctor,dtor}
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 22/33] hexagon: Convert __pte_free_tlb() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 06/33] mm: Convert ptlock_alloc() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 10/33] mm: Convert pmd_ptlock_free() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 04/33] mm: add utility functions for ptdesc
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 09/33] mm: Convert ptlock_init() to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 19/33] arm: Convert various functions to use ptdescs
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 03/33] pgtable: Create struct ptdesc
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 02/33] s390: Use pt_frag_refcount for pagetables
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• [PATCH 00/33] Split ptdesc from struct page
  • From: "Vishal Moola (Oracle)" <vishal.moola@xxxxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v3 00/19] arch: Consolidate <asm/fb.h>
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH v3 13/19] arch/parisc: Implement fb_is_primary_device() under arch/parisc
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 19/19] arch/x86: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 14/19] arch/parisc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 12/19] arch/parisc: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 15/19] arch/powerpc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 10/19] video: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 09/19] arch/mips: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 18/19] arch/sparc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 17/19] arch/sparc: Implement fb_is_primary_device() in source file
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 04/19] arch/arm64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 01/19] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 03/19] arch/arm: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 11/19] video: Move HP PARISC STI core code to shared location
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 05/19] arch/ia64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 00/19] arch: Consolidate <asm/fb.h>
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 08/19] arch/m68k: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 02/19] arch/arc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v3 06/19] arch/loongarch: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v2 02/19] arch/arc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• RE: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH v2 15/19] arch/powerpc: Implement <asm/fb.h> with generic helpers
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• RE: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 08/19] arch/m68k: Implement <asm/fb.h> with generic helpers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v2 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: kernel behaviour, was Re: dash behaviour
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: instrumentation, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: kernel behaviour, was Re: dash behaviour
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: kernel behaviour, was Re: dash behaviour
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• instrumentation, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS ca3e36cc6eed6c195a39cdcd740c9d46349bc78b
  • From: kernel test robot <lkp@xxxxxxxxx>
• kernel behaviour, was Re: dash behaviour
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: dash behaviour, was Re: core dump analysis
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• dash behaviour, was Re: core dump analysis
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: patchwork-bot+netdevbpf@xxxxxxxxxx
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v4] nubus: Don't list slot resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: [PATCH 12/18] arch/parisc: Implement fb_is_primary_device() under arch/parisc
  • From: Rolf Eike Beer <eike-kernel@xxxxxxxxx>
• Re: [PATCH 00/18] arch: Consolidate <asm/fb.h>
  • From: Rolf Eike Beer <eike-kernel@xxxxxxxxx>
• Re: [PATCH v2 09/19] arch/mips: Implement <asm/fb.h> with generic helpers
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v2 02/19] arch/arc: Implement <asm/fb.h> with generic helpers
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• [PATCH v2 15/19] arch/powerpc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 14/19] arch/parisc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 19/19] arch/x86: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 17/19] arch/sparc: Implement fb_is_primary_device() in source file
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 05/19] arch/ia64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 07/19] arch/m68k: Merge variants of fb_pgprotect() into single function
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 08/19] arch/m68k: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 02/19] arch/arc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 04/19] arch/arm64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 00/19] arch: Consolidate <asm/fb.h>
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 13/19] arch/parisc: Implement fb_is_primary_device() under arch/parisc
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 10/19] video: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 16/19] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 11/19] video: Move HP PARISC STI core code to shared location
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 18/19] arch/sparc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 01/19] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 03/19] arch/arm: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 12/19] arch/parisc: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 09/19] arch/mips: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v2 06/19] arch/loongarch: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH 01/18] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
  • From: Shahab Vahedi <Shahab.Vahedi@xxxxxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Jakub Kicinski <kuba@xxxxxxxxxx>
• RE: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH 01/18] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Sean Anderson <seanga2@xxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Simon Horman <horms@xxxxxxxxxx>
• Re: [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Sean Anderson <seanga2@xxxxxxxxx>
• [PATCH net-next] net: sunhme: move asm includes to below linux includes
  • From: Simon Horman <horms@xxxxxxxxxx>
• Re: [PATCH 01/18] fbdev: Prepare generic architecture helpers
  • From: Daniel Vetter <daniel@xxxxxxxx>
• Re: [PATCH 01/18] fbdev: Prepare generic architecture helpers
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• [PATCH 18/18] arch/x86: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 17/18] arch/sparc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 15/18] arch/sh: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 16/18] arch/sparc: Implement fb_is_primary_device() in source file
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 14/18] arch/powerpc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 13/18] arch/parisc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 10/18] video: Move HP PARISC STI core code to shared location
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 05/18] arch/ia64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 07/18] arch/m68k: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 06/18] arch/loongarch: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 12/18] arch/parisc: Implement fb_is_primary_device() under arch/parisc
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 11/18] arch/parisc: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 09/18] video: Remove trailing whitespaces
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 04/18] arch/arm64: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 08/18] arch/mips: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 03/18] arch/arm: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 01/18] fbdev: Prepare generic architecture helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 02/18] arch/arc: Implement <asm/fb.h> with generic helpers
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH 00/18] arch: Consolidate <asm/fb.h>
  • From: Thomas Zimmermann <tzimmermann@xxxxxxx>
• [PATCH v4] nubus: Don't list slot resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [RFC PATCH v3] nubus: Don't list slot resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• [linux-next:master] BUILD REGRESSION 6a53bda3aaf3de5edeea27d0b1d8781d067640b6
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Justin Forbes <jforbes@xxxxxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH v1] m68k/mm: Use correct bit number in _PAGE_SWP_EXCLUSIVE comment
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
  • From: Shahab Vahedi <Shahab.Vahedi@xxxxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [geert-m68k:for-next] BUILD SUCCESS 1ea3bb3e4b767d074c8215c515e959c6420908bf
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [RFC PATCH v3] nubus: Don't list slot resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 98485defdf60678296754fce632b05c68f447029
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [RFC PATCH v3] nubus: Don't list slot resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
  • From: Vineet Gupta <vgupta@xxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 00/21] dma-mapping: unify support for cache flushes
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 00/21] dma-mapping: unify support for cache flushes
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: Robin Murphy <robin.murphy@xxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 17/21] ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 17/21] ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
• Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: "Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx>
• Re: [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
  • From: "Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx>
• Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: "Lad, Prabhakar" <prabhakar.csengg@xxxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Ard Biesheuvel <ardb@xxxxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
• Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: Conor Dooley <conor@xxxxxxxxxx>
• Re: [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
  • From: Conor Dooley <conor@xxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Justin Forbes <jforbes@xxxxxxxxxxxxxxxxx>
• core dump analysis, was Re: stack smashing detected
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 97e3e4fbb21e8f1f46dc0d13e72bd6b588626645
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: Christoph Hellwig <hch@xxxxxx>
• [gerg-m68knommu:armnommu 3/3] arch/arm/include/asm/glue-cache.h:126:2: error: Unknown cache maintenance model
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH 02/21] xtensa: dma-mapping: use normal cache invalidation rules
  • From: Max Filippov <jcmvbkbc@xxxxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 10/21] csky: dma-mapping: skip invalidating before DMA from device
  • From: Guo Ren <guoren@xxxxxxxxxx>
• Re: [PATCH 16/21] ARM: dma-mapping: bring back dmac_{clean,inv}_range
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: Robin Murphy <robin.murphy@xxxxxxx>
• [PATCH 21/21] dma-mapping: replace custom code with generic implementation
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 19/21] ARM: dma-mapping: use generic form of arch_sync_dma_* helpers
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 18/21] ARM: drop SMP support for ARM11MPCore
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 17/21] ARM: dma-mapping: use arch_sync_dma_for_{device,cpu}() internally
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 16/21] ARM: dma-mapping: bring back dmac_{clean,inv}_range
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 15/21] ARM: dma-mapping: always invalidate WT caches before DMA
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 14/21] parisc: dma-mapping: use regular flush/invalidate ops
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 13/21] arc: dma-mapping: skip invalidating before bidirectional DMA
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 12/21] mips: dma-mapping: split out cache operation logic
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 11/21] mips: dma-mapping: skip invalidating before bidirectional DMA
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 10/21] csky: dma-mapping: skip invalidating before DMA from device
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 07/21] powerpc: dma-mapping: always clean cache in _for_device() op
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 06/21] powerpc: dma-mapping: minimize for_cpu flushing
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 05/21] powerpc: dma-mapping: split out cache operation logic
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 04/21] microblaze: dma-mapping: skip extra DMA flushes
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 03/21] sparc32: flush caches in dma_sync_*for_device
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 02/21] xtensa: dma-mapping: use normal cache invalidation rules
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 01/21] openrisc: dma-mapping: flush bidirectional mappings
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• [PATCH 00/21] dma-mapping: unify support for cache flushes
  • From: Arnd Bergmann <arnd@xxxxxxxxxx>
• Re: gdb failure: "core file format not supported"
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: gdb failure: "core file format not supported"
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: gdb failure: "core file format not supported"
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [RFC PATCH v3] nubus: Don't list slot resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
  • From: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
• Re: [PATCH v3 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
• Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
• [PATCH v3 14/14] xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 13/14] sparc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 12/14] sh: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 11/14] sh: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 10/14] powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 09/14] powerpc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 08/14] nios2: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 07/14] nios2: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 06/14] m68k: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 04/14] csky: drop ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 01/14] arm: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v3 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH v2 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: Zi Yan <ziy@xxxxxxxxxx>
• Re: [PATCH v2 11/14] sh: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Zi Yan <ziy@xxxxxxxxxx>
• Re: [PATCH v2 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Zi Yan <ziy@xxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Brad Boyer <flar@xxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v2 14/14] xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 13/14] sparc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 12/14] sh: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 11/14] sh: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 10/14] powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 09/14] powerpc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 08/14] nios2: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 07/14] nios2: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 06/14] m68k: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 04/14] csky: drop ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 01/14] arm: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH v2 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: kernel test robot <lkp@xxxxxxxxx>
• [PATCH v4] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• Re: [PATCH 06/14] m68k: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: Pass a pointer to virt_to_pfn() virt_to_page()
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH] m68k: Pass a pointer to virt_to_pfn() virt_to_page()
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• [PATCH] m68k: Pass a pointer to virt_to_pfn() virt_to_page()
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Zi Yan <ziy@xxxxxxxxxx>
• Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 14/14] xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Max Filippov <jcmvbkbc@xxxxxxxxx>
• [PATCH 14/14] xtensa: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 13/14] sparc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 12/14] sh: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 11/14] sh: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 10/14] powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 09/14] powerpc: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 08/14] nios2: drop ranges for definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 07/14] nios2: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 06/14] m68k: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 05/14] ia64: don't allow users to override ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 04/14] csky: drop ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 03/14] arm64: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 01/14] arm: reword ARCH_FORCE_MAX_ORDER prompt and help text
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH 00/14] arch,mm: cleanup Kconfig entries for ARCH_FORCE_MAX_ORDER
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2] nubus: Don't list card resources by default
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v2] nubus: Don't list card resources by default
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH] nvme-tcp: fix nvme_tcp_term_pdu to match spec
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH] nubus: Avoid scanning "private" card resources
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: gdb failure: "core file format not supported"
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH] nubus: Avoid scanning "private" card resources
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH] nubus: Remove proc entries before adding them
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [geert-m68k:for-next] BUILD SUCCESS fda1941b8eab786112afe91088fa0a1ed4880360
  • From: kernel test robot <lkp@xxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS b55f773e598a93232307dc61278cdf081adad7fa
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH] m68k: Kconfig.machine: remove obsolete configs ROMBASE and ROMSIZE
  • From: Greg Ungerer <gerg@xxxxxxxxxx>
• Re: [PATCH] nvme-tcp: fix nvme_tcp_term_pdu to match spec
  • From: Sagi Grimberg <sagi@xxxxxxxxxxx>
• [PATCH] nvme-tcp: fix nvme_tcp_term_pdu to match spec
  • From: Caleb Sander <csander@xxxxxxxxxxxxxxx>
• Re: [PATCH] nvme-tcp: Fix implicit padding in struct nvme_tcp_term_pdu
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] nvme-tcp: Fix implicit padding in struct nvme_tcp_term_pdu
  • From: Caleb Sander <csander@xxxxxxxxxxxxxxx>
• Re: [PATCH] m68k: remove obsolete config NO_KERNEL_MSG
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: Kconfig.machine: remove obsolete configs ROMBASE and ROMSIZE
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] m68k: Kconfig.machine: remove obsolete configs ROMBASE and ROMSIZE
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• [PATCH] m68k: remove obsolete config NO_KERNEL_MSG
  • From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
• [PATCH] nvme-tcp: Fix implicit padding in struct nvme_tcp_term_pdu
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v1] nubus: Remove redunant driver match function
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH v1] nubus: Remove redunant driver match function
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re:Re: [PATCH v1] nubus: Remove redunant driver match function
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH AUTOSEL 4.14 4/9] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 4.19 4/9] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.4 04/12] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.15 06/17] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.10 05/15] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 6.1 07/29] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 6.1 06/29] m68k: mm: Fix systems with memory at end of 32-bit address space
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 6.2 07/30] m68k: Only force 030 bus error if PC not in exception table
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 6.2 06/30] m68k: mm: Fix systems with memory at end of 32-bit address space
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: drop uclinux.org
  • From: Greg Ungerer <gerg@xxxxxxxxxxxxxx>
• Re: [PATCH] drivers/mmc/core/bus: Delete redundant match function
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH v1] nubus: Remove redunant driver match function
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH v1] nubus: Remove redunant driver match function
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH v1] nubus: Remove redunant driver match function
  • From: Lizhe <sensor1010@xxxxxxx>
• Re: [PATCH v4 14/36] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v4 14/36] m68k: Implement the new page table range API
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: [PATCH v4 14/36] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v4 14/36] m68k: Implement the new page table range API
  • From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• [PATCH v3 01/38] Kconfig: introduce HAS_IOPORT option and select it as necessary
  • From: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
• [PATCH] nubus: Partially revert proc_create_single_data() conversion
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH] nubus: Drop noop match function
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] nubus: Drop noop match function
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 28230bb22d4ea73c91d7e934dc2f162f931733ae
  • From: kernel test robot <lkp@xxxxxxxxx>
• [PATCH] nubus: Drop noop match function
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Baoquan He <bhe@xxxxxxxxxx>
• Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [GIT PULL] m68k fixes for v6.3
  • From: pr-tracker-bot@xxxxxxxxxx
• Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>
• [GIT PULL] m68k fixes for v6.3
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Baoquan He <bhe@xxxxxxxxxx>
• Re: [PATCH v5 12/26] riscv: Remove COMMAND_LINE_SIZE from uapi
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH v2] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v13 0/3] Add kernel seccomp support for m68k
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 513138a14063760ef611f18ba76c5c7915ff8cdd
  • From: kernel test robot <lkp@xxxxxxxxx>
• [geert-m68k:for-v6.3] BUILD SUCCESS e36a82bebbf7da814530d5a179bef9df5934b717
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Baoquan He <bhe@xxxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH 01/10] alpha: fix livelock in uaccess
  • From: patchwork-bot+linux-riscv@xxxxxxxxxx
• Re: [PATCH v2] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v5 00/26] Remove COMMAND_LINE_SIZE from uapi
  • From: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx>
• Re: [PATCH v2] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] m68k: defconfig: Update defconfigs for v6.3-rc1
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v5 26/26] riscv: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 25/26] s390: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 24/26] mips: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 23/26] powerpc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 22/26] xtensa: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 21/26] x86: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 20/26] parisc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 19/26] sparc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 18/26] microblaze: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 17/26] arm64: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 16/26] m68k: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 15/26] arc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 14/26] alpha: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 13/26] asm-generic: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 12/26] riscv: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 11/26] xtensa: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 10/26] sparc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 09/26] powerpc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 08/26] parisc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 07/26] mips: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 06/26] microblaze: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 05/26] m68k: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 04/26] ia64: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 03/26] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 02/26] arm64: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 01/26] alpha: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v5 00/26] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• [PATCH v3 2/2] arch/*/io.h: remove ioremap_uc in some architectures
  • From: Baoquan He <bhe@xxxxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alex@xxxxxxxx>
• [PATCH v4 23/24] mips: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 24/24] s390: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 22/24] powerpc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 21/24] xtensa: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 20/24] x86: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 19/24] parisc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 18/24] sparc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 17/24] microblaze: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 16/24] arm64: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 15/24] m68k: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 14/24] arc: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 13/24] alpha: Remove empty <uapi/asm/setup.h>
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• Re: [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v4 12/24] asm-generic: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 11/24] xtensa: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 10/24] sparc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 09/24] powerpc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 08/24] parisc: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 07/24] mips: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 06/24] microblaze: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 05/24] m68k: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 04/24] ia64: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 02/24] arm64: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 01/24] alpha: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH v4 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Deepak Gupta <debug@xxxxxxxxxxxx>
• Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
  • From: Baoquan He <bhe@xxxxxxxxxx>
• Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
• Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
  • From: Edward Cree <ecree.xilinx@xxxxxxxxx>
• [PATCH v5 01/17] asm-generic/iomap.h: remove ARCH_HAS_IOREMAP_xx macros
  • From: Baoquan He <bhe@xxxxxxxxxx>
• [PATCH v2] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH] MAINTAINERS: drop uclinux.org
  • From: Greg Ungerer <gerg@xxxxxxxxxxxxxx>
• [PATCH v3 13/34] m68k: Implement the new page table range API
  • From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx>
• Re: [PATCH mm-unstable v1 00/26] mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures with swap PTEs
  • From: patchwork-bot+linux-riscv@xxxxxxxxxx
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH 08/10] parisc: fix livelock in uaccess
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH] input/misc: hp_sdc_rtc: mark an unused function as __maybe_unused
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 08/10] parisc: fix livelock in uaccess
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• [PATCH] MAINTAINERS: drop uclinux.org
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: [PATCH mm-unstable v1 19/26] riscv/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH mm-unstable v1 19/26] riscv/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 08/10] parisc: fix livelock in uaccess
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH] m68k: mm: Move initrd phys_to_virt handling after paging_init()
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: mm: Move initrd phys_to_virt handling after paging_init()
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH] m68k: mm: Move initrd phys_to_virt handling after paging_init()
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• [PATCH v7 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH v13 0/3] Add kernel seccomp support for m68k
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] m68k: mm: Move initrd phys_to_virt handling after paging_init()
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] SUNRPC: Ensure test case arrays are properly terminated
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] SUNRPC: Let Kunit tests run with some enctypes compiled out
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [git pull] m68knommu changes for v6.3
  • From: pr-tracker-bot@xxxxxxxxxx
• [PATCH v2 12/30] m68k: Implement the new page table range API
  • From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: David Hildenbrand <david@xxxxxxxxxx>
• [PATCH] SUNRPC: Ensure test case arrays are properly terminated
  • From: Chuck Lever <cel@xxxxxxxxxx>
• [PATCH] SUNRPC: Let Kunit tests run with some enctypes compiled out
  • From: Chuck Lever <cel@xxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Chuck Lever III <chuck.lever@xxxxxxxxxx>
• Re: [PATCH] kunit: tool: Add support for m68k under QEMU
  • From: David Gow <davidgow@xxxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Mike Rapoport <rppt@xxxxxxxxxx>
• [PATCH] kunit: tool: Add support for m68k under QEMU
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 5/7] io_uring: use __xchg if possible
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: use __xchg instead of internal helper
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 6/7] qed: use __xchg if possible
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 4/7] llist: simplify __llist_del_all
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 3/7] arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 2/7] linux/include: add non-atomic version of xchg
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 1/7] arch: rename all internal names __xchg to __arch_xchg
  • From: Andi Shyti <andi.shyti@xxxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• [git pull] m68knommu changes for v6.3
  • From: Greg Ungerer <gerg@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Finn Thain <fthain@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH AUTOSEL 6.1 26/49] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 4.14 10/11] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 4.19 11/13] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.4 13/19] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.10 19/27] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 5.15 21/36] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• [PATCH AUTOSEL 6.2 28/53] m68k: Check syscall_trace_enter() return code
  • From: Sasha Levin <sashal@xxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Kars de Jong <jongk@xxxxxxxxxxxxxx>
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg
  • From: Andrzej Hajda <andrzej.hajda@xxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Chuck Lever III <chuck.lever@xxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Chuck Lever III <chuck.lever@xxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Kars de Jong <jongk@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Kars de Jong <jongk@xxxxxxxxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Chuck Lever III <chuck.lever@xxxxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v2 00/41] RPCSEC GSS krb5 enhancements
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] m68k: fix for systems with memory at end of 32-bit address space
  • From: Kars de Jong <jongk@xxxxxxxxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
• [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH v5 0/7] Introduce __xchg, non-atomic xchg
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg
  • From: Andrzej Hajda <andrzej.hajda@xxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [GIT PULL] m68k updates for v6.3
  • From: pr-tracker-bot@xxxxxxxxxx
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Booting 6.2.0-rc8 on HP 9000/425t - all memory is reserved
  • From: Kars de Jong <jongk@xxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernel versions 6.x don't boot on Amiga 4000
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Kernel versions 6.x don't boot on Amiga 4000
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [geert-m68k:m68k-v6.2] BUILD SUCCESS b1b5209c1e80a9c9912dfe38986fabbc71a2904e
  • From: kernel test robot <lkp@xxxxxxxxx>
• [geert-m68k:master] BUILD SUCCESS 0fcf6b2d92cbb554127e342ca27adefa569ff63f
  • From: kernel test robot <lkp@xxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
• [GIT PULL] m68k updates for v6.3
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: API for setting multiple PTEs at once
  • From: Rolf Eike Beer <eb@xxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v6 13/41] mm: Make pte_mkwrite() take a VMA
  • From: Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx>
• Re: [PATCH 15/17] m68k: Implement the new page table range API
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• Re: [PATCH 2/2] sh: initialize max_mapnr
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH 1/2] m68k/nommu: add missing definition of ARCH_PFN_OFFSET
  • From: David Hildenbrand <david@xxxxxxxxxx>
• Re: [PATCH 15/17] m68k: Implement the new page table range API
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 15/17] m68k: Implement the new page table range API
  • From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
• Re: [PATCH 15/17] m68k: Implement the new page table range API
  • From: Michael Schmitz <schmitzmic@xxxxxxxxx>
• [PATCH 15/17] m68k: Implement the new page table range API
  • From: "Matthew Wilcox (Oracle)" <willy@xxxxxxxxxxxxx>
• Re: [PATCH v4 00/18] gpiolib cleanups
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [PATCH v4 00/18] gpiolib cleanups
  • From: Bartosz Golaszewski <brgl@xxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: "Arnd Bergmann" <arnd@xxxxxxxx>
• Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi
  • From: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/2] m68k/nommu: add missing definition of ARCH_PFN_OFFSET
  • From: Greg Ungerer <gerg@xxxxxxxxxxxxxx>
• Re: [PATCH v3 09/24] powerpc: Remove COMMAND_LINE_SIZE from uapi
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 2/2] sh: initialize max_mapnr
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>