Linux Sparc

• Thread Index

• Re: Netra T1-105 reboot hang (prtfconf/openprom module related?)
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Tadeusz Struk <tadeusz.struk@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Tadeusz Struk <tadeusz.struk@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [crypto / sparc64] cryptomgr_test OOPS
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [crypto / sparc64] cryptomgr_test OOPS
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: mroos@xxxxxxxx
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: Josh Juran <jjuran@xxxxxxxxx>
• Re: [patch V3] lib: GCD: add binary GCD algorithm
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [patch V3] lib: GCD: add binary GCD algorithm
  • From: zengzhaoxiu@xxxxxxx
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Joerg Abraham <joerg.abraham@xxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH] sparc64: recognize and support Sonoma CPU type
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/2] sparc: Implement and wire up modalias_show for vio.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc/pci: Refactor dev_archdata initialization into pci_init_dev_archdata
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 4/5] sparc/defconfigs: Remove CONFIG_IPV6_PRIVACY
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: kernel boot broken since 4.5 on t5220 ( niagara2 ) machine
  • From: Mike Frysinger <vapier@xxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: Meelis Roos <mroos@xxxxxxxx>
• [PATCH] x86/locking/rwsem: Cleanup ____down_write()
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: kernel boot broken since 4.5 on t5220 ( niagara2 ) machine
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: kernel boot broken since 4.5 on t5220 ( niagara2 ) machine
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH v5 2/4] printk/nmi: warn when some message has been lost in NMI context
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• kernel boot broken since 4.5 on t5220 ( niagara2 ) machine
  • From: Joerg Abraham <joerg.abraham@xxxxxxxxx>
• Re: [PATCH v5 0/4] Cleaning printk stuff in NMI context
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [Crash-utility] [PATCH V3 0/3] sparc64 support for crash utility
  • From: Dave Anderson <anderson@xxxxxxxxxx>
• Re: [Crash-utility] [PATCH V3 0/3] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [Crash-utility] [PATCH V3 0/3] sparc64 support for crash utility
  • From: Dave Anderson <anderson@xxxxxxxxxx>
• Re: [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 21/23] sparc: remove ARCH_WANT_OPTIONAL_GPIOLIB
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [Crash-utility] [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
  • From: Dave Anderson <anderson@xxxxxxxxxx>
• Re: [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [PATCH V3 3/3] crash-utility: Support for sparc64 architecture
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH V3 1/3] Use proper size for task_struct->flags
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH V3 1/3] Use proper size for task_struct->flags
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH V3 3/3] crash-utility: Support for sparc64 architecture
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH V3 0/3] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [PATCH] aeroflex/greth: fix warning about unused variable
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH] aeroflex/greth: fix warning about unused variable
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH] openprom: fix uninitialized warnings
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 5/5] sparc32: drop superfluous cast in calls to __nocache_pa()
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 4/5] sparc32: fix build with STRICT_MM_TYPECHECKS
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 3/5] sparc32: use proper prototype for trapbase
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 2/5] sparc32: drop local prototype in kgdb_32
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 1/5] sparc32: drop hardcoding trap_level in kgdb_trap
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 0/5] sparc32: kgdb_32 and STRICT_MM_TYPECHECKS updates
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 21/23] sparc: remove ARCH_WANT_OPTIONAL_GPIOLIB
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module autoloading support for vio
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module autoloading support for vio
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Enable module autoloading support for vio
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH v5 2/4] printk/nmi: warn when some message has been lost in NMI context
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v5 3/4] printk/nmi: increase the size of NMI buffer and make it configurable
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v5 1/4] printk/nmi: generic solution for safe printk in NMI
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v5 4/4] printk/nmi: flush NMI messages on the system panic
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v5 0/4] Cleaning printk stuff in NMI context
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] sparc64: recognize and support Sonoma CPU type
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: Please advise on dealing with compiler issue
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: recognize and support Sonoma CPU type
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• Please advise on dealing with compiler issue
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v4 1/5] printk/nmi: generic solution for safe printk in NMI
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: console noise after commit c1e9b3b0eea
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• [PATCH 21/23] sparc: remove ARCH_WANT_OPTIONAL_GPIOLIB
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: console noise after commit c1e9b3b0eea
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• console noise after commit c1e9b3b0eea
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• [PATCH] sparc64: recognize and support Sonoma CPU type
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 1/2] sparc: Implement and wire up modalias_show for vio.
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH 1/2] sparc: Implement and wire up modalias_show for vio.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/2] sparc: Implement and wire up vio_hotplug for vio.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Enable module autoloading support for vio
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH V3 00/29] bitops: add parity functions
  • From: zengzhaoxiu@xxxxxxx
• [PATCH V3 08/29] Add sparc-specific parity functions
  • From: zengzhaoxiu@xxxxxxx
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore v3
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore v3
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH] sparc/pci: Refactor dev_archdata initialization into pci_init_dev_archdata
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore v3
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH] sparc/pci: Refactor dev_archdata initialization into pci_init_dev_archdata
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Enable module aliases for vio on sparc/sparc64
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Kernel panic under qemu-system-sparc64 when adding kb_ps2/kdmouse DT nodes
  • From: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>
• Re: Kernel panic under qemu-system-sparc64 when adding kb_ps2/kdmouse DT nodes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Kernel panic under qemu-system-sparc64 when adding kb_ps2/kdmouse DT nodes
  • From: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>
• Enable module aliases for vio on sparc/sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Bisected: RED State Exception in 4.5 on E420R
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 08/11] ia64, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH v11 06/60] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• [PATCH v11 58/60] PCI: Introduce resource_disabled()
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• Re: [PATCH 08/11] ia64, rwsem: provide __down_write_killable
  • From: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>
• [PATCH 08/11] ia64, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 06/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 03/11] xtensa, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 11/11] locking, rwsem: provide down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 02/11] locking, rwsem: drop explicit memory barriers
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 01/11] locking, rwsem: get rid of __down_write_nested
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 0/11] introduce down_write_killable for rw_semaphore v3
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 07/11] alpha, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 04/11] sh, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 05/11] sparc, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 09/11] s390, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Bisected: RED State Exception in 4.5 on E420R
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
• Re: [PATCH v2 08/30] Add sparc-specific parity functions
  • From: Zeng Zhaoxiu <zhaoxiu.zeng@xxxxxxxxx>
• Re: [PATCH v2 08/30] Add sparc-specific parity functions
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 08/30] Add sparc-specific parity functions
  • From: Josip Rodin <joy@xxxxxxxxxxxxxx>
• Re: [PATCH 2/2] sh, rwsem: drop superfluous arch specific implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sh, rwsem: drop superfluous arch specific implementation
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 2/2] sh, rwsem: drop superfluous arch specific implementation
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH v2 08/30] Add sparc-specific parity functions
  • From: zengzhaoxiu@xxxxxxx
• [PATCH] sparc, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• RED State Exception in 4.5 on E420R
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH 1/2] xtensa, rwsem: drop superfluous arch specific implementation
  • From: Max Filippov <jcmvbkbc@xxxxxxxxx>
• Re: [PATCH v4 1/5] printk/nmi: generic solution for safe printk in NMI
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 2/2] sh, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 1/2] xtensa, rwsem: drop superfluous arch specific implementation
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 02/11] locking, rwsem: drop explicit memory barriers
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v4 2/5] printk/nmi: use IRQ work only when ready
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [PATCH v4 5/5] printk/nmi: flush NMI messages on the system panic
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [PATCH v4 1/5] printk/nmi: generic solution for safe printk in NMI
  • From: Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
• Re: [PATCH 02/11] locking, rwsem: drop explicit memory barriers
  • From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
• Re: [PATCH 01/11] locking, rwsem: get rid of __down_write_nested
  • From: Davidlohr Bueso <dave@xxxxxxxxxxxx>
• [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 04/11] alpha, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 0/11] introduce down_write_killable for rw_semaphore v2
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 06/11] s390, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 07/11] sh, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 08/11] sparc, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 01/11] locking, rwsem: get rid of __down_write_nested
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 09/11] xtensa, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 02/11] locking, rwsem: drop explicit memory barriers
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 11/11] locking, rwsem: provide down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 05/11] ia64, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v4 5/5] printk/nmi: flush NMI messages on the system panic
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH v2 3/4] exit_thread: accept a task parameter to be exited
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH v4] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH v4] sparc64: Reduce TLB flushes during hugepte changes
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v4 5/5] printk/nmi: flush NMI messages on the system panic
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH v4 2/5] printk/nmi: use IRQ work only when ready
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4 1/5] printk/nmi: generic solution for safe printk in NMI
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4 5/5] printk/nmi: flush NMI messages on the system panic
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4 3/5] printk/nmi: warn when some message has been lost in NMI context
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4 4/5] printk/nmi: increase the size of NMI buffer and make it configurable
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4 0/5] Cleaning printk stuff in NMI context
  • From: Petr Mladek <pmladek@xxxxxxxx>
• tulip hangs under load on sparc64
  • From: alexmcwhirter@xxxxxxxxxx
• Re: [PATCH v4] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH 4/5] sparc/defconfigs: Remove CONFIG_IPV6_PRIVACY
  • From: Borislav Petkov <bp@xxxxxxxxx>
• [PATCH] silo: Fix signed overflow issues with 'clock-frequency'.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc: Write up preadv2/pwritev2 syscalls.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Minor tweak to silo regarding GPT labeled drives
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v4] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 10/31] Add sparc-specific parity functions
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 10/31] Add sparc-specific parity functions
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 10/31] Add sparc-specific parity functions
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 10/31] Add sparc-specific parity functions
  • From: Zeng Zhaoxiu <zhaoxiu.zeng@xxxxxxxxx>
• Re: [PATCH 10/31] Add sparc-specific parity functions
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 10/31] Add sparc-specific parity functions
  • From: "zhaoxiu.zeng" <zhaoxiu.zeng@xxxxxxxxx>
• Re: [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH v4] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: [Patch V2 2/2] sparc64 changes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [Patch V2 2/2] sparc64 changes
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [Patch V2 1/2] sparc64 changes for gdb-7.6
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [Patch V2 0/2] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH v3] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: [PATCH v2] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [Crash-utility] [PATCH 0/2] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH v2] sparc/PCI: Fix for panic while enabling SR-IOV
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH 0/2] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH 2/2] sparc64 changes
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• [PATCH 1/2] sparc64 changes for gdb-7.6
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• Re: [Crash-utility] [PATCH 0/2] sparc64 support for crash utility
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Fwd: [Crash-utility] [PATCH 0/2] sparc64 support for crash utility
  • From: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx>
• Re: [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: Convert naked unsigned uses to unsigned int
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: Fix misspellings in comments.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH v2 1/5] printk/nmi: Generic solution for safe printk in NMI
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: alexmcwhirter@xxxxxxxxxx
• [PATCH RFC] PCI: Fix for panic while enabling SR-IOV
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
• Re: [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [PATCH] sparc: Convert naked unsigned uses to unsigned int
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: alexmcwhirter@xxxxxxxxxx
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sparc64: Reduce TLB flushes on hugetlb PTE change
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: sparc64: Reduce TLB flushes on hugetlb PTE change
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: Fix misspellings in comments.
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• sparc64: Reduce TLB flushes on hugetlb PTE change
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: James Morris <james.l.morris@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: alexmcwhirter@xxxxxxxxxx
• Re: Kernels 4.+ are breaking rsync?
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: alexmcwhirter@xxxxxxxxxx
• [PATCH] sparc: Fix misspellings in comments.
  • From: Adam Buchbinder <adam.buchbinder@xxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• sparc64 hugetlb: possible irq lock inversion dependency detected
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: kbuild test robot <lkp@xxxxxxxxx>
• [PATCH] sparc64: Add support for Application Data Integrity (ADI)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH 1/2] topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files.
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 2/2] numa, mm, cleanup: remove redundant NODE_DATA macro from asm header files.
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v7] Add sun4v_wdt watchdog driver
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7] Add sun4v_wdt watchdog driver
  • From: Wim Van Sebroeck <wim@xxxxxxxxx>
• Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable
  • From: Daniel Thompson <daniel.thompson@xxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 04/11] alpha, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 09/11] xtensa, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 01/11] locking, rwsem: get rid of __down_write_nested
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 10/11] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 02/11] locking, rwsem: drop explicit memory barriers
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 06/11] s390, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 11/11] locking, rwsem: provide down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 07/11] sh, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 08/11] sparc, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 05/11] ia64, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [PATCH 0/11] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code,Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
• Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH 1/1] [RFC]sparc64: enable cpu hotplug feature
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code,Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: Tomi Valkeinen <tomi.valkeinen@xxxxxx>
• [PATCH v10 04/59] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• [PATCH v10 57/59] PCI: Introduce resource_disabled()
  • From: Yinghai Lu <yinghai@xxxxxxxxxx>
• [PATCH 2/2] numa, mm, cleanup: remove redundant NODE_DATA macro from asm header files.
  • From: David Daney <ddaney.cavm@xxxxxxxxx>
• [PATCH 1/2] topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files.
  • From: David Daney <ddaney.cavm@xxxxxxxxx>
• [PATCH 0/2] NUMA related header file cleanups.
  • From: David Daney <ddaney.cavm@xxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: mroos@xxxxxxxx
• Re: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: mroos@xxxxxxxx
• Re: Invalid sk_policy[] access
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Invalid sk_policy[] access
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
  • From: Meelis Roos <mroos@xxxxxxxx>
• Invalid sk_policy[] access (was Re: Recent spontaneous reboots on multiple machines)
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• [PATCH 0/3] video/fbdev: avoid module usage in non-modular sparc code
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 1/3] drivers/video: make fbdev/sunxvr500.c explicitly non-modular
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 2/3] drivers/video: make fbdev/sunxvr1000.c explicitly non-modular
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH 3/3] drivers/video: make fbdev/sunxvr2500.c explicitly non-modular
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: Recent spontaneous reboots on multiple machines
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Re: [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: Recent spontaneous reboots on multiple machines
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: Invalid SIGSEGV from sparc64_set_context ()
  • From: Ilya Malakhov <ilmalakhovthefirst@xxxxxxxxx>
• Re: Invalid SIGSEGV from sparc64_set_context ()
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [RFC 11/12 v1] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v7 0/9] virtio DMA API, yet again
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH v7 0/9] virtio DMA API, yet again
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH v7 0/9] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Invalid SIGSEGV from sparc64_set_context ()
  • From: Ilya Malakhov <ilmalakhovthefirst@xxxxxxxxx>
• Re: Recent spontaneous reboots on multiple machines
  • From: Meelis Roos <mroos@xxxxxxxx>
• Kernels 4.+ are breaking rsync?
  • From: Alex McWhirter <alexmcwhirter@xxxxxxxxxx>
• Today's kernel on sun4u
  • From: Frans van Berckel <fberckel@xxxxxxxxx>
• Re: Recent spontaneous reboots on multiple machines
  • From: Sowmini Varadhan <sowmini.varadhan@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: Recent spontaneous reboots on multiple machines
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH v7 9/9] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v2] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v7 5/9] virtio_ring: Support DMA APIs
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v7 0/9] virtio DMA API, yet again
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
• Re: [PATCH v7 5/9] virtio_ring: Support DMA APIs
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [RFC 07/12] sh, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC 10/12] x86, rwsem: simplify __down_write
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC 07/12] sh, rwsem: provide __down_write_killable
  • From: Sergei Shtylyov <sergei.shtylyov@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 9/9] vring: Use the DMA API on Xen
  • From: David Vrabel <david.vrabel@xxxxxxxxxx>
• Re: [RFC 10/12] x86, rwsem: simplify __down_write
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH v7 1/9] dma: Provide simple noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 4/9] vring: Introduce vring_use_dma_api()
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 3/9] s390/dma: Allow per device dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 2/9] alpha/dma: use common noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 5/9] virtio_ring: Support DMA APIs
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 6/9] virtio: Add improved queue allocation API
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 9/9] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 8/9] virtio_pci: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 7/9] virtio_mmio: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v7 0/9] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] sparc64: Reduce TLB flushes during hugepage unmap
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [RFC 0/12] introduce down_write_killable for rw_semaphore
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 01/12] locking, rwsem: get rid of __down_write_nested
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 02/12] locking, rwsem: drop explicit memory barriers
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 03/12] locking, rwsem: introduce basis for down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 04/12] alpha, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 05/12] ia64, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 06/12] s390, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 07/12] sh, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 10/12] x86, rwsem: simplify __down_write
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 08/12] sparc, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 09/12] xtensa, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 11/12] x86, rwsem: provide __down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• [RFC 12/12] locking, rwsem: provide down_write_killable
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH v6 6/9] virtio: Add improved queue allocation API
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v6 3/9] s390/dma: Allow per device dma ops
  • From: Cornelia Huck <cornelia.huck@xxxxxxxxxx>
• Re: [PATCH v6 6/9] virtio: Add improved queue allocation API
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH v6 0/9] virtio DMA API, yet again
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH] sparc64: Reduce TLB flushes during hugepage unmap
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v6 9/9] vring: Use the DMA API on Xen
  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again
  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
• [PATCH v6 1/9] dma: Provide simple noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 3/9] s390/dma: Allow per device dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 0/9] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v6 9/9] vring: Use the DMA API on Xen
  • From: David Vrabel <david.vrabel@xxxxxxxxxx>
• [PATCH v6 4/9] vring: Introduce vring_use_dma_api()
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 6/9] virtio: Add improved queue allocation API
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 5/9] virtio_ring: Support DMA APIs
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 7/9] virtio_mmio: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 8/9] virtio_pci: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 9/9] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v6 2/9] alpha/dma: use common noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v5 04/10] vring: Introduce vring_use_dma_api()
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH v5 04/10] vring: Introduce vring_use_dma_api()
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v5 04/10] vring: Introduce vring_use_dma_api()
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH v5 04/10] vring: Introduce vring_use_dma_api()
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 00/10] virtio DMA API, yet again
  • From: Wei Liu <wei.liu2@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH v5 00/10] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v5 00/10] virtio DMA API, yet again
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: [PATCH v7] Add sun4v_wdt watchdog driver
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v5 00/10] virtio DMA API, yet again
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: [PATCH v7] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v7] Add sun4v_wdt watchdog driver
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• [PATCH v7] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Stanislav Kholmanskikh <stanislav.kholmanskikh@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Maciej W. Rozycki" <macro@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Stanislav Kholmanskikh <stanislav.kholmanskikh@xxxxxxxxxx>
• Re: [PATCH v5 00/10] virtio DMA API, yet again
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: David Vrabel <david.vrabel@xxxxxxxxxx>
• Re: [RFC] hugepages on sparc
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v5 01/10] dma: Provide simple noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 02/10] alpha/dma: use common noop dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 03/10] s390/dma: Allow per device dma ops
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 05/10] virtio_ring: Support DMA APIs
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 04/10] vring: Introduce vring_use_dma_api()
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 06/10] virtio: Add improved queue allocation API
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 07/10] virtio_mmio: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 09/10] vring: Use the DMA API on Xen
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 08/10] virtio_pci: Use the DMA API if enabled
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 10/10] vring: Add a module parameter to force-enable the DMA API
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v5 00/10] virtio DMA API, yet again
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Re: [RFC] hugepages on sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v6] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [RFC] hugepages on sparc
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 30/31] Add debugger entry points for SPARC
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 30/31] Add debugger entry points for SPARC
  • From: Jeffrey Merkey <jeffmerkey@xxxxxxxxx>
• Re: [PATCH 30/31] Add debugger entry points for SPARC
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 30/31] Add debugger entry points for SPARC
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH 30/31] Add debugger entry points for SPARC
  • From: Jeffrey Merkey <jeffmerkey@xxxxxxxxx>
• Re: [RFC] hugepages on sparc
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v5] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• [PATCH] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• [PATCH v5] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Leonid Yegoshin <Leonid.Yegoshin@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [RFC] hugepages on sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [RFC] hugepages on sparc
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• Re: [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Maciej W. Rozycki" <macro@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Maciej W. Rozycki" <macro@xxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Ralf Baechle <ralf@xxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH] documentation: Add disclaimer
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH] documentation: Add disclaimer
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH 06/17] arch: Set IORESOURCE_SYSTEM_RAM flag for System RAM
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs
  • From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v2 05/16] ptrace: in PEEK_SIGINFO, check syscall bitness, not task bitness
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 06/16] auditsc: For seccomp events, log syscall compat state using in_compat_syscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 08/16] ext4: In ext4_dir_llseek, check syscall bitness directly
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 07/16] staging/lustre: Switch from is_compat_task to in_compat_syscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 10/16] net/xfrm_user: Use in_compat_syscall to deny compat syscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 09/16] net/sctp: Use in_compat_syscall for sctp_getsockopt_connectx3
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 00/16] compat: Introduce and use in_compat_syscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 11/16] firewire: Use in_compat_syscall to check ioctl compatness
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 12/16] efivars: Use in_compat_syscall to check for compat callers
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 13/16] amdkfd: Use in_compat_syscall to check open() caller type
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 15/16] uhid: Check write() bitness using in_compat_syscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 16/16] x86/compat: Remove is_compat_task
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 14/16] input: Redefine INPUT_COMPAT_TEST as in_compat_syscall()
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 04/16] seccomp: Check in_compat_syscall, not is_compat_task, in strict mode
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 03/16] sparc/syscall: Fix syscall_get_arch
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH v2 01/16] compat: Add in_compat_syscall to ask whether we're in a compat syscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [PATCH v3] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH v3] Add sun4v_wdt watchdog driver
  • From: Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>
• Re: [PATCH v3] Add sun4v_wdt watchdog driver
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/2] n2rng: documentation, add DT bindings, vendor prefixes
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [v3,11/41] mips: reuse asm-generic/barrier.h
  • From: Will Deacon <will.deacon@xxxxxxx>