Linux PA RISC

• Thread Index

• [PATCH 11/31] sparc/iommu: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 12/31] mn10300: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 14/31] sparc32/io-unit: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 16/31] s390: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 15/31] sparc32/iommu: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 18/31] nios2: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 17/31] ia64/sba_iommu: remove sba_sg_address
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 20/31] avr32: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 19/31] arc: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 22/31] metag: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 21/31] blackfin: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 24/31] xtensa: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 26/31] openrisc: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 25/31] frv: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 28/31] powerpc: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 27/31] mips: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 30/31] intel-iommu: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 29/31] parisc: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 31/31] dma-mapping-common: skip kmemleak checks for page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 23/31] sh: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH 04/31] x86/pci-nommu: handle page-less SG entries
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH v7 4/6] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH v7 2/6] mm: mlock: Add new mlock system call
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH v7 0/6] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V6 4/6] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V6 2/6] mm: mlock: Add new mlock system call
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• [PATCH -next] parisc: Define ioremap_uc and ioremap_wc
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH V6 0/6] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V6 2/6] mm: mlock: Add new mlock system call
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V6 4/6] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH V5 4/7] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH V5 2/7] mm: mlock: Add new mlock system call
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• [PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V5 4/7] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V5 0/7] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V5 2/7] mm: mlock: Add new mlock system call
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Re: [PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH V4 4/6] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V4 0/6] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: Meelis Roos <mroos@xxxxxxxx>
• Meld je nu aan voor meer info / Apply now for more info
  • From: Standard lening bedrijf <rpkaya@xxxxxxxxxxxx>
• [GIT PULL] parisc fixes for v4.2
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 1/3] x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• Re: [PATCH 1/3] x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: Bug#706050: logrotate: spurious "error: getting file ACL" messages
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: Bug#706050: logrotate: spurious "error: getting file ACL" messages
  • From: Paul Martin <pm@xxxxxxxxxx>
• Re: [3/3] IRQ: Print "unexpected IRQ" messages consistently across architectures
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: Bug#706050: logrotate: spurious "error: getting file ACL" messages
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: Helge Deller <deller@xxxxxx>
• Re: [3/3] IRQ: Print "unexpected IRQ" messages consistently across architectures
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• Re: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• RE: [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH] parisc: mm: Fix a memory leak related to pmd not attached to the pgd
  • From: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
• Re: [PATCH 3/3] IRQ: Print "unexpected IRQ" messages consistently across architectures
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [3/3] IRQ: Print "unexpected IRQ" messages consistently across architectures
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• [PATCH 1/3] x86, irq: Rename VECTOR_UNDEFINED and VECTOR_RETRIGGERED to IRQ_*
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• [PATCH 3/3] IRQ: Print "unexpected IRQ" messages consistently across architectures
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• [PATCH 2/3] x86, irq: Clarify "No irq handler" message
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• [PATCH 0/3] IRQ trivial clarifications
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• Re: Bug#706050: logrotate: spurious "error: getting file ACL" messages
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Bug#706050: logrotate: spurious "error: getting file ACL" messages
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [GIT PULL] parisc fixes for v4.2
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH V3 0/5] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V3 0/5] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH V3 2/5] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH V3 2/5] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH V3 2/5] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
• Re: [PATCH V3 0/5] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V3 4/5] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V3 2/5] mm: mlock: Add new mlock, munlock, and munlockall system calls
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V3 0/5] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH][RFC] parisc: Fix some PTE/TLB race conditions and optimize __flush_tlb_range based on timing results
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Frans Klaver <fransklaver@xxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Frans Klaver <fransklaver@xxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
• [PATCH 3.19.y-ckt 061/146] parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures
  • From: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
• Re: [PATCH] stifb: Implement hardware accelerated copyarea
  • From: ⁣ ⁣ <lausgans@xxxxxxxxx>
• [3.19.y-ckt stable] Patch "parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures" has been added to staging queue
  • From: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
• Re: [PATCH] stifb: Implement hardware accelerated copyarea
  • From: Helge Deller <deller@xxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH] stifb: Implement hardware accelerated copyarea
  • From: lausgans@xxxxxxxxx
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [RESEND PATCH V2 2/3] Add mlockall flag for locking pages on fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [RESEND PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Generic kernel features that need architecture(parisc) support
  • From: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
• [PATCH 3.16.y-ckt 039/110] parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures
  • From: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
• [added to the 3.18 stable tree] parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• [PATCH 4.0 109/148] parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 2/3] Add mlockall flag for locking pages on fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V2 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH V2 1/3] Add mmap flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [RESEND PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [Patch v3 23/36] parisc, irq: Use access helper irq_data_get_affinity_mask()
  • From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
• Re: [PATCH][RFC] parisc: Optimize TLB flush functions based on timing results
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH][RFC] parisc: Optimize TLB flush functions based on timing results
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH][RFC] parisc: Optimize TLB flush functions based on timing results
  • From: Helge Deller <deller@xxxxxx>
• [PATCH][RFC] parisc: Optimize TLB flush functions based on timing results
  • From: Helge Deller <deller@xxxxxx>
• [RESEND PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [RESEND PATCH 1/3] Add flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [RESEND PATCH 2/3] Add mlockall flag for locking pages on fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH 00/15] Replace module_init with device_initcall in non modules
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 11/15] parisc64: don't use module_init for non-modular core perf code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 10/15] parisc: don't use module_init for non-modular core pdc_cons code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [3.16.y-ckt stable] Patch "parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures" has been added to staging queue
  • From: Luis Henriques <luis.henriques@xxxxxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [GIT PULL] parisc fixes for v4.1
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Michal Hocko <mhocko@xxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH] Fix crashes due to stack randomization on stack-grows-upwards architectures
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/3] Add flag to request pages are locked after page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH 2/3] Add mlockall flag for locking pages on fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH 0/3] Allow user to request memory to be locked on page fault
  • From: Eric B Munson <emunson@xxxxxxxxxx>
• [PATCH v2 10/10] parisc: use for_each_sg()
  • From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: Boaz Harrosh <boaz@xxxxxxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: Akinobu Mita <akinobu.mita@xxxxxxxxx>
• Re: [PATCH] scatterlist: enable sg chaining for all architectures
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Access to 64-bit hppa machine for GCC development
  • From: Helge Deller <deller@xxxxxx>
• Access to 64-bit hppa machine for GCC development
  • From: Kyrill Tkachov <kyrylo.tkachov@xxxxxxx>
• Re: 4.0 parisc regression: memory leak?
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: 4.0 parisc regression: memory leak?
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• 4.0 parisc regression: memory leak?
  • From: Meelis Roos <mroos@xxxxxxxx>
• [GIT PULL] parisc fixes for v4.1
  • From: Helge Deller <deller@xxxxxx>
• [PATCH v10 22/29] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [PATCH] parisc: Replace PT_NLEVELS with CONFIG_PGTABLE_LEVELS
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH] ALSA: remove deprecated use of pci api
  • From: Takashi Iwai <tiwai@xxxxxxx>
• [PATCH] parisc: Replace PT_NLEVELS with CONFIG_PGTABLE_LEVELS
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH] ALSA: remove deprecated use of pci api
  • From: Quentin Lambert <lambert.quentin@xxxxxxxxx>
• Re: [PATCH v2 2/6] input/serio: drop pci_ids dependency
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• Re: [PATCH] sound: Use const struct ac97_quirk
  • From: Takashi Iwai <tiwai@xxxxxxx>
• [PATCH] sound: Use const struct ac97_quirk
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: Dmitry the Zuryanovich <dreadbit@xxxxxxxxx>
• [PATCH v9 22/30] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: Grant Grundler <grantgrundler@xxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: Grant Grundler <grantgrundler@xxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: E Class and SCSI (53c700 driver)
  • From: Helge Deller <deller@xxxxxx>
• [PATCH v2 2/6] input/serio: drop pci_ids dependency
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• linux-next: manual merge of the akpm-current tree with the parisc-hd tree
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• [PATCH 42/86] input/serio: use uapi/linux/pci_ids.h directly
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• [PATCH 81/86] input/serio: drop pci_ids dependency
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• [GIT PULL] parisc fixes for v4.0
  • From: Helge Deller <deller@xxxxxx>
• [PATCH v8 22/30] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v7 22/31] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [PATCH] parisc: Eliminate sg_virt_addr() and private scatterlist.h
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc: Eliminate sg_virt_addr() and private scatterlist.h
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [PATCH] parisc: Eliminate sg_virt_addr() and private scatterlist.h
  • From: Matthew Wilcox <matthew.r.wilcox@xxxxxxxxx>
• Re: [PATCH v2] mm: don't count preallocated pmds
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• [PATCH v2] mm: don't count preallocated pmds
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] mm: don't count preallocated pmds
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH] mm: don't count preallocated pmds
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] mm: don't count preallocated pmds
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• [PATCH] mm: don't count preallocated pmds
  • From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
• Re: [PATCH] parisc: compat Fix siginfo_t -> compat_siginfo_t conversion on big endian
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH] parisc: Do not hardcode PAGE_SIZE dependend values in assembler
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Do not hardcode PAGE_SIZE dependend values in assembler
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Fix pmd code to depend on PT_NLEVELS value, not on CONFIG_64BIT
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH, v2] parisc: Add compile-time check when adding new syscalls
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: compat Fix siginfo_t -> compat_siginfo_t conversion on big endian
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Add compile-time check when adding new syscalls
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] parisc: fix pmd accounting with 3-level page tables
  • From: Graham Gower <graham.gower@xxxxxxxxx>
• [PATCH 22/32] parisc: copy_thread(): rename 'arg' argument to 'kthread_arg'
  • From: Alex Dowad <alexinbeijing@xxxxxxxxx>
• [PATCH] parisc: fix pmd accounting with 3-level page tables
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• [PATCH v2 14/22] parisc: %pf is only for function pointers
  • From: Scott Wood <scottwood@xxxxxxxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH 14/22] parisc: %pF is only for function pointers
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: [PATCH 14/22] parisc: %pF is only for function pointers
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 14/22] parisc: %pF is only for function pointers
  • From: Scott Wood <scottwood@xxxxxxxxxxxxx>
• Re: [PATCH 14/22] parisc: %pF is only for function pointers
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH 14/22] parisc: %pF is only for function pointers
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH 14/22] parisc: %pF is only for function pointers
  • From: Scott Wood <scottwood@xxxxxxxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: Graham Gower <graham.gower@xxxxxxxxx>
• Re: [PATCH v3 0/8] switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: BUG: non-zero nr_pmds on freeing mm: -1
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• BUG: non-zero nr_pmds on freeing mm: -1
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: Pre-DEBIAN 8.0 install images for HPPA architecture (debian-ports unstable release)
  • From: Helge Deller <deller@xxxxxx>
• Re: Pre-DEBIAN 8.0 install images for HPPA architecture (debian-ports unstable release)
  • From: Harri Haataja <realblades@xxxxxxxxx>
• [PATCH v6 22/30] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• [PATCH v5 21/29] parisc/PCI: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [PATCH v3 8/8] x86: switch to using asm-generic for seccomp.h
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH v3 4/8] mips: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 2/8] arm: use asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 1/8] seccomp: allow COMPAT sigreturn overrides
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 8/8] x86: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 0/8] switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 5/8] parisc: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 7/8] sparc: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 3/8] microblaze: use asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v3 6/8] powerpc: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2] seccomp: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v4 22/30] PCI/Parisc: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: [PATCH v2] seccomp: switch to using asm-generic for seccomp.h
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v4 22/30] PCI/Parisc: Use pci_scan_root_bus() for simplicity
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• [PATCH v2] seccomp: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] seccomp: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH] seccomp: switch to using asm-generic for seccomp.h
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• [PATCH] seccomp: switch to using asm-generic for seccomp.h
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• [PATCH v4 22/30] PCI/Parisc: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH v3 22/30] PCI/Parisc: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: Pre-DEBIAN 8.0 install images for HPPA architecture (debian-ports unstable release)
  • From: Frank Benke <frank@xxxxxxxxxxx>
• Pre-DEBIAN 8.0 install images for HPPA architecture (debian-ports unstable release)
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address - optimized patches
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [PATCH 00/27] Convert seq_<foo> output calls to return void
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 26/27] parisc: Remove use of seq_printf return value
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: Helge Deller <deller@xxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• [GIT PULL] parisc architecture patches for v3.20
  • From: Helge Deller <deller@xxxxxx>
• Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] fs/binfmt_som: Drop kernel support for HP-UX SOM binaries
  • From: Helge Deller <deller@xxxxxx>
• Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  • From: Paul Bolle <pebolle@xxxxxxxxxx>
• Re: RFC arch/sh/kernel/traps_64.c - unclear if/else construct (hpux compat layer)
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: hpux - Remove HPUX syscall numbers
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: hpux - Remove hpux gateway page
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: hpux - Delete files in hpux subdirectory
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: hpux - Do not compile hpux subdirectory
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: hpux - Drop support for HP-UX binaries
  • From: Helge Deller <deller@xxxxxx>
• Re: Video option for a big endian machine?
  • From: Alex Deucher <alexdeucher@xxxxxxxxx>
• Re: Little endianness
  • From: ⁣ ⁣ <lausgans@xxxxxxxxx>
• Re: Little endianness
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Video option for a big endian machine?
  • From: lausgans@xxxxxxxxx
• Re: Little endianness
  • From: lausgans@xxxxxxxxx
• Re: Little endianness
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Little endianness
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Little endianness
  • From: Held Bier <lausgans@xxxxxxxxx>
• Re: [PATCH] MODULE_DEVICE_TABLE: fix gscps2
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• [PATCH] MODULE_DEVICE_TABLE: fix gscps2
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] parisc: Add error checks when building up signal trampoline handler
  • From: Helge Deller <deller@xxxxxx>
• [PATCH v11 16/19] mm: vmalloc: pass additional vm_flags to __vmalloc_node_range()
  • From: Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx>
• RFC arch/sh/kernel/traps_64.c - unclear if/else construct
  • From: Nicholas Mc Guire <der.herr@xxxxxxx>
• [PATCH v10 14/17] mm: vmalloc: pass additional vm_flags to __vmalloc_node_range()
  • From: Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx>
• [PATCH v9 14/17] mm: vmalloc: pass additional vm_flags to __vmalloc_node_range()
  • From: Andrey Ryabinin <a.ryabinin@xxxxxxxxxxx>
• linux-next: tidy up of trees
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• [PATCH v2 22/30] PCI/Parisc: Use pci_scan_root_bus() for simplicity
  • From: Yijing Wang <wangyijing@xxxxxxxxxx>
• [PATCH 1/9] video: Deletion of checks before the function call "iounmap"
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH 0/9] video: fbdev: Deletion of some unnecessary checks
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH v2 08/10] PCI, parisc: clip firmware assigned resource under parent bridge's
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• Re: [PATCH 1/3] module_arch_freeing_init(): new hook for archs before module->module_init freed.
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 08/10] PCI, parisc: clip firmware assigned resource under parent bridge's
  • From: Helge Deller <deller@xxxxxx>
• [PATCH 08/10] PCI, parisc: clip firmware assigned resource under parent bridge's
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• [PATCH] parisc: Wire up execveat syscall
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 0/6] kbuild: refactor Makefiles related with cc-version
  • From: Michal Marek <mmarek@xxxxxxx>
• Re: [PATCH 1/3] module_arch_freeing_init(): new hook for archs before module->module_init freed.
  • From: Hans-Christian Egtvedt <egtvedt@xxxxxxxxxxxx>
• [PATCH 1/3] module_arch_freeing_init(): new hook for archs before module->module_init freed.
  • From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
• [PATCH v2 37/40] parisc: macro whitespace fixes
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• [PATCH v2 12/40] parisc/uaccess: fix sparse errors
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 11/13] ALSA: Deletion of checks before the function call "iounmap"
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH 11/13] ALSA: Deletion of checks before the function call "iounmap"
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH] arch: parisc: kernel: smp: Remove unused function
  • From: Rickard Strandqvist <rickard_strandqvist@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] serial: fix parisc boot hang
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] arch: parisc: kernel: sys_parisc: Remove some unused functions
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] arch: parisc: kernel: sys_parisc: Remove some unused functions
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] arch: parisc: kernel: sys_parisc: Remove some unused functions
  • From: Rickard Strandqvist <rickard_strandqvist@xxxxxxxxxxxxxxxxxx>
• [PATCH] serial: fix parisc boot hang
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
• Re: serial console problem with kernel 3.18.0-rc4
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH 4/13] incorrect use of init_completion fixup
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• [GIT PULL] parisc fix for v3.19
  • From: Helge Deller <deller@xxxxxx>
• [PATCH 4/13] incorrect use of init_completion fixup
  • From: Nicholas Mc Guire <der.herr@xxxxxxx>
• Re: [PATCH 2/6] kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: Helge Deller <deller@xxxxxx>
• [PATCH repost 12/16] parisc/uaccess: fix sparse errors
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• [PATCH 0/6] kbuild: refactor Makefiles related with cc-version
  • From: Masahiro Yamada <yamada.m@xxxxxxxxxxxxxxxx>
• [PATCH 2/6] kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion
  • From: Masahiro Yamada <yamada.m@xxxxxxxxxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [PATCH 12/18] parisc/uaccess: fix sparse errors
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Someone want to sponsor a HPPA box for the HPPA port?
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Max Filippov <jcmvbkbc@xxxxxxxxx>
• [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• [PATCH] arch: uapi: asm: mman.h: Support MADV_FREE for madvise()
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Dave Land RIP
  • From: Helge Deller <deller@xxxxxx>
• Re: [RFC] add a struct page* parameter to dma_map_ops.unmap_page
  • From: Mitchel Humpherys <mitchelh@xxxxxxxxxxxxxx>
• Re: [RFC] add a struct page* parameter to dma_map_ops.unmap_page
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
• Re: [Xen-devel] [RFC] add a struct page* parameter to dma_map_ops.unmap_page
  • From: David Vrabel <david.vrabel@xxxxxxxxxx>
• [RFC] add a struct page* parameter to dma_map_ops.unmap_page
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
• [GIT PULL] parisc architecture patches for v3.18
  • From: Helge Deller <deller@xxxxxx>
• serial console problem with kernel 3.18.0-rc4
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH -next 1/2] seq_puts: Convert to return void and convert uses too.
  • From: Petr Mladek <pmladek@xxxxxxx>
• Re: [PATCH -next 1/2] seq_puts: Convert to return void and convert uses too.
  • From: Mark Brown <broonie@xxxxxxxxxx>
• [PATCH] parisc: Drop CONFIG_64BIT usage in userspace exported headers
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls
  • From: Helge Deller <deller@xxxxxx>
• [PATCH -next 0/2] seq: Convert seq_puts and seq_putc to return void
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH -next 1/2] seq_puts: Convert to return void and convert uses too.
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: STI text console for ATI FireGL cards?
  • From: Alex <lausgans@xxxxxxxxx>
• [PATCH v6 08/48] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH v5 08/48] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 33/44] avr32: atngw100: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 33/44] avr32: atngw100: Register with kernel poweroff handler
  • From: Hans-Christian Egtvedt <egtvedt@xxxxxxxxxxxx>
• [PATCH v3 08/47] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 11/11] sound: ad1889: Fix probable mask then right shift defects
  • From: Takashi Iwai <tiwai@xxxxxxx>
• [PATCH 11/11] sound: ad1889: Fix probable mask then right shift defects
  • From: Joe Perches <joe@xxxxxxxxxxx>
• [PATCH 00/11] treewide: mask then shift defects and style updates
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: Lennox Wu <lennox.wu@xxxxxxxxx>
• Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Re: [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [PATCH] parisc: fix out-of-register compiler error in ldcw inline assembler function
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: use BUILD_BUG() instead of undefined functions
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Wire up bpf syscall
  • From: Helge Deller <deller@xxxxxx>
• [PATCH v2 08/47] kernel: Move pm_power_off to common code
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [GIT PULL] parisc architecture patch for v3.18
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: [GIT PULL] parisc architecture patch for v3.18
  • From: Helge Deller <deller@xxxxxx>
• Re: [GIT PULL] parisc architecture patch for v3.18
  • From: One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>
• [GIT PULL] parisc architecture patch for v3.18
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• [PATCH] parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures
  • From: Helge Deller <deller@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Helge Deller <deller@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Lee Jones <lee.jones@xxxxxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Lee Jones <lee.jones@xxxxxxxxxx>
• Re: [PATCH 32/44] arm64: psci: Register with kernel poweroff handler
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Pavel Machek <pavel@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 44/44] kernel: Remove pm_power_off
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
  • From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Helge Deller <deller@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Helge Deller <deller@xxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: systemd on hppa and number of free RT signals
  • From: Jeroen Roovers <jer@xxxxxxxxxx>
• systemd on hppa and number of free RT signals
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: David Daney <ddaney.cavm@xxxxxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH 20/44] power/reset: restart-poweroff: Register with kernel poweroff handler
  • From: Andrew Lunn <andrew@xxxxxxx>
• Re: [PATCH 23/44] power/reset: qnap-poweroff: Register with kernel poweroff handler
  • From: Andrew Lunn <andrew@xxxxxxx>
• Re: [PATCH 21/44] power/reset: gpio-poweroff: Register with kernel poweroff handler
  • From: Andrew Lunn <andrew@xxxxxxx>
• Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Andrew Lunn <andrew@xxxxxxx>
• Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Andrew Lunn <andrew@xxxxxxx>
• Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 35/44] m68k: Register with kernel poweroff handler
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 04/44] m68k: Replace mach_power_off with pm_power_off
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 31/44] arm: Register with kernel poweroff handler
  • From: Nicolas Ferre <nicolas.ferre@xxxxxxxxx>
• Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Lee Jones <lee.jones@xxxxxxxxxx>
• Re: [PATCH 18/44] mfd: twl4030-power: Register with kernel poweroff handler
  • From: Lee Jones <lee.jones@xxxxxxxxxx>
• Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Philippe Rétornaz <philippe.retornaz@xxxxxxxxx>
• [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 04/44] m68k: Replace mach_power_off with pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 37/44] sh: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 36/44] mips: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 17/44] mfd: tps65910: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 20/44] power/reset: restart-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 44/44] kernel: Remove pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 42/44] efi: Register poweroff handler with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 43/44] hwmon: (ab8500) Call kernel_power_off instead of pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 31/44] arm: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 18/44] mfd: twl4030-power: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 41/44] x86: pmc_atom: Register poweroff handler with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 25/44] power/reset: vexpress-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 24/44] power/reset: msm-powroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 40/44] x86: intel-mid: Drop registration of dummy poweroff handlers
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 38/44] x86: lguest: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 19/44] ipmi: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 39/44] x86: ce4100: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 35/44] m68k: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 30/44] acpi: Register poweroff handler with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 28/44] x86: olpc: Register xo1 poweroff handler with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 16/44] mfd: tps6586x: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 15/44] mfd: dm355evm_msp: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 02/44] memory: emif: Use API function to determine poweroff capability
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 11/44] mfd: retu: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 13/44] mfd: max8907: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 33/44] avr32: atngw100: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 09/44] mfd: palmas: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 32/44] arm64: psci: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 34/44] ia64: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 14/44] mfd: tps80031: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 29/44] staging: nvec: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 27/44] x86: apm: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 23/44] power/reset: qnap-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 26/44] x86: iris: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 10/44] mfd: axp20x: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 21/44] power/reset: gpio-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 22/44] power/reset: as3722-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH 01/44] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [RFC PATCH 07/16] c6x: support poweroff through poweroff handler call chain
  • From: Mark Salter <msalter@xxxxxxxxxx>
• Re: [RFC PATCH 15/16] power/reset: restart-poweroff: Register with kernel poweroff handler
  • From: Sebastian Reichel <sre@xxxxxxxxxx>
• Re: [RFC PATCH 05/16] arm64: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [RFC PATCH 05/16] arm64: support poweroff through poweroff handler call chain
  • From: Catalin Marinas <catalin.marinas@xxxxxxx>
• [GIT PULL] parisc late fix for v3.17
  • From: Helge Deller <deller@xxxxxx>
• Re: [Xen-devel] [RFC PATCH 14/16] x86/xen: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [Xen-devel] [RFC PATCH 14/16] x86/xen: support poweroff through poweroff handler call chain
  • From: David Vrabel <david.vrabel@xxxxxxxxxx>
• [PATCH] parisc: Fix serial console for machines with serial port on superio chip
  • From: Helge Deller <deller@xxxxxx>
• Re: [RFC PATCH 10/16] mips: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: Aw: Re: serial console broken in v3.17-rc6 ?
  • From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
• Aw: Re: serial console broken in v3.17-rc6 ?
  • From: "Helge Deller" <deller@xxxxxx>
• Re: [RFC PATCH 10/16] mips: support poweroff through poweroff handler call chain
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Re: serial console broken in v3.17-rc6 ?
  • From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
• [RFC PATCH 02/16] hwmon: (ab8500) Call kernel_power_off instead of pm_power_off
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 01/16] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 05/16] arm64: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 04/16] arm: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 03/16] parisc: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 06/16] avr32: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 07/16] c6x: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 08/16] ia64: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 09/16] metag: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 10/16] mips: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 11/16] sh: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 12/16] unicore32: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 13/16] x86: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 14/16] x86/xen: support poweroff through poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 15/16] power/reset: restart-poweroff: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 16/16] mfd: palmas: Register with kernel poweroff handler
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [RFC PATCH 00/16] kernel: Add support for poweroff handler call chain
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 1/6] video: fbdev: stifb.c: use container_of to resolve stifb_info from fb_info
  • From: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
• Re: serial console broken in v3.17-rc6 ?
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] parisc:Remove unnecessary FIXMES in init.c
  • From: Nicholas Krause <yocto6@xxxxxxxxx>
• Re: [PATCH] parisc:Remove unnecessary FIXMES in init.c
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCH] parisc:Remove unnecessary FIXMES in init.c
  • From: nick <yocto6@xxxxxxxxx>
• Re: [PATCH] parisc:Remove unnecessary FIXMES in init.c
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH] parisc:Remove unnecessary FIXMES in init.c
  • From: Nicholas Krause <yocto6@xxxxxxxxx>
• Re: serial console broken in v3.17-rc6 ?
  • From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
• Re: FIX MES in init.c
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: FIX MES in init.c
  • From: Helge Deller <deller@xxxxxx>
• serial console broken in v3.17-rc6 ?
  • From: Helge Deller <deller@xxxxxx>
• [GIT PULL] parisc fixes for v3.17
  • From: Helge Deller <deller@xxxxxx>
• [PATCH 2/5] parisc: Set CONFIG_NET=y in defconfigs
  • From: Michal Marek <mmarek@xxxxxxx>
• [PATCH] parisc: Only use -mfast-indirect-calls option for 32-bit kernel builds
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• FIX MES in init.c
  • From: nick <yocto6@xxxxxxxxx>
• [PATCH] parisc: pdc_stable.c: Avoid potential stack overflows
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] parisc: pdc_stable.c: Cleaning up unnecessary use of memset in conjunction with strncpy
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] Fix end_of_stack() fn and location of stack canary for archs using STACK_GROWSUP
  • From: Aaron Tomlin <atomlin@xxxxxxxxxx>
• Re: [PATCH] Fix end_of_stack() fn and location of stack canary for archs using STACK_GROWSUP
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• [PATCH 1/6] video: fbdev: stifb.c: use container_of to resolve stifb_info from fb_info
  • From: Fabian Frederick <fabf@xxxxxxxxx>
• [PATCH 0/6] video: fbdev: use container_of where possible
  • From: Fabian Frederick <fabf@xxxxxxxxx>
• [PATCH] Fix end_of_stack() fn and location of stack canary for archs using STACK_GROWSUP
  • From: Chuck Ebbert <cebbert.lkml@xxxxxxxxx>
• Re: [PATCHv3] Implement gcc 64bit atomic operations and fix the broken 8/16 bit ones
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [PATCHv3] Implement gcc 64bit atomic operations and fix the broken 8/16 bit ones
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: pdc_stable.c: Cleaning up unnecessary use of memset in conjunction with strncpy
  • From: Rickard Strandqvist <rickard_strandqvist@xxxxxxxxxxxxxxxxxx>
• [GIT PULL] parisc fixes for v3.17
  • From: Helge Deller <deller@xxxxxx>
• [PATCHv3] Implement gcc 64bit atomic operations and fix the broken 8/16 bit ones
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: [PATCH 1/3] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>
• Re: [PATCH 1/3] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Greg KH <greg@xxxxxxxxx>
• [PATCH 1/3 v2] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>
• Re: [PATCH 1/3] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>
• Re: [PATCH 1/3] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Greg KH <greg@xxxxxxxxx>
• [PATCH 1/3] parisc/uapi: Add definition of TIOC[SG]RS485
  • From: Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>
• Re: [RFC PATCHv2] 64bit LWS CAS
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: [RFC PATCHv2] 64bit LWS CAS
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Wire up seccomp, getrandom and memfd_create syscalls
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: [PATCH v3] arch: Kconfig: Let all architectures set endian explicitly
  • From: Chen Gang <gang.chen.5i5j@xxxxxxxxx>
• Re: Sym2 scsi hang on boot on sparc64
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Sym2 scsi hang on boot on sparc64
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: Sym2 scsi hang on boot on sparc64
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Sym2 scsi hang on boot on sparc64
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Sym2 scsi hang on boot on sparc64
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: struct sigaction sa_restorer field
  • From: Mike Frysinger <vapier@xxxxxxxxxx>
• [PATCH 13/19] drivers: parisc: fix %d confusingly prefixed with 0x in format string
  • From: Hans Wennborg <hans@xxxxxxxxxx>
• [patch] [PARISC] sys_hpux: NUL terminator is one past the end
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [RFC PATCHv2] 64bit LWS CAS
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: [RFC PATCHv2] 64bit LWS CAS
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: [RFC PATCHv2] 64bit LWS CAS
  • From: Helge Deller <deller@xxxxxx>
• [RFC PATCHv2] 64bit LWS CAS
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• [GIT PULL] parisc fixes for v3.16
  • From: Helge Deller <deller@xxxxxx>
• Re: Compiling a 32bit kernel fails
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: Compiling a 32bit kernel fails
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Compiling a 32bit kernel fails
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• [PATCH] parisc: Remove SA_RESTORER define
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Aw: Re: struct sigaction sa_restorer field
  • From: "Helge Deller" <deller@xxxxxx>
• Re: struct sigaction sa_restorer field
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [PATCH 15/43] parisc: Use get_signal() signal_setup_done()
  • From: Richard Weinberger <richard@xxxxxxxxxxxxx>
• Re: struct sigaction sa_restorer field
  • From: "Helge Deller" <deller@xxxxxx>
• struct sigaction sa_restorer field
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• processor.c: Fix me to rewrite init_percpu_pro
  • From: Nick Krause <xerofoify@xxxxxxxxx>
• [PATCH] parisc: Eliminate memset after alloc_bootmem_pages
  • From: Himangi Saraogi <himangi774@xxxxxxxxx>
• Re: [PATCH] parisc: Remove FIXME comment
  • From: Nick Krause <xerofoify@xxxxxxxxx>
• Re: [PATCH] parisc: Remove FIXME comment
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] parisc: Remove FIXME comment
  • From: Nick Krause <xerofoify@xxxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: [PATCH] parisc: Remove FIXME comment
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] parisc: Remove FIXME comment
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: Remove FIXME comment
  • From: Nicholas Krause <xerofoify@xxxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [patch NOT added to the 3.12 stable tree] parisc,metag: Do not hardcode maximum userspace stack size
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: Helge Deller <deller@xxxxxx>
• Re: [RFC PATCH] 64bit LWS CAS
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• [RFC PATCH] 64bit LWS CAS
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: John David Anglin <dave.anglin@xxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: Helge Deller <deller@xxxxxx>
• Re: Implementing 64bit atomic gcc built-ins
  • From: "Carlos O'Donell" <carlos@xxxxxxxxxxxxxxxx>
• Implementing 64bit atomic gcc built-ins
  • From: Guy Martin <gmsoft@xxxxxxxxxxxx>
• [PATCH 3.14 08/66] parisc,metag: Do not hardcode maximum userspace stack size
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [GIT PULL] parisc updates for v3.16
  • From: Helge Deller <deller@xxxxxx>
• Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel [SOLVED]
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: drop unused defines and header includes
  • From: Helge Deller <deller@xxxxxx>
• [PATCH] parisc: fix fanotify_mark() syscall on 32bit compat kernel
  • From: Helge Deller <deller@xxxxxx>
• [STABLE][PATCH] parisc,metag: Do not hardcode maximum userspace stack size
  • From: Helge Deller <deller@xxxxxx>
• Re: Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel
  • From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
• Aw: Re: [PATCH] fix fanotify_mark() breakage on big endian 32bit kernel
  • From: "Helge Deller" <deller@xxxxxx>
• Re: [PATCH] parisc: Remove sizeof(frame) from call to get_sigframe
  • From: Jiri Kosina <jkosina@xxxxxxx>
• Re: [PATCH] parisc: Remove sizeof(frame) from call to get_sigframe
  • From: One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>