* Re: [PATCH] powerpc/selftests: Use gettid() instead of getppid() for null_syscall
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
Shuah Khan, Michael Ellerman
Cc: linuxppc-dev, linux-kernel, linux-kselftest
In-Reply-To: <0ad62673d3e063f848e7c99d719bb966efd433e8.1622809833.git.christophe.leroy@csgroup.eu>
On Fri, 4 Jun 2021 12:31:09 +0000 (UTC), Christophe Leroy wrote:
> gettid() is 10% lighter than getppid(), use it for null_syscall selftest.
Applied to powerpc/next.
[1/1] powerpc/selftests: Use gettid() instead of getppid() for null_syscall
https://git.kernel.org/powerpc/c/a1ea0ca8a6f17d7b79bbc4d05dd4e6ca162d8f15
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/signal32: Remove impossible #ifdef combinations
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a069a348ee3c2fe3123a5a93695c2b35dc42cb40.1623340691.git.christophe.leroy@csgroup.eu>
On Thu, 10 Jun 2021 15:58:34 +0000 (UTC), Christophe Leroy wrote:
> PPC_TRANSACTIONAL_MEM is only on book3s/64
> SPE is only on booke
>
> PPC_TRANSACTIONAL_MEM selects ALTIVEC and VSX
>
> Therefore, within PPC_TRANSACTIONAL_MEM sections,
> ALTIVEC and VSX are always defined while SPE never is.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/signal32: Remove impossible #ifdef combinations
https://git.kernel.org/powerpc/c/ac3d085368b3abf19b24d8505b897454c7372855
cheers
^ permalink raw reply
* Re: [PATCH v1 01/12] powerpc: Rework PPC_RAW_xxx() macros for prefixed instructions
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
jniethe5, naveen.n.rao, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <5d146b31b943e7ad674894421db4feef54804b9b.1621506159.git.christophe.leroy@csgroup.eu>
On Thu, 20 May 2021 10:23:00 +0000 (UTC), Christophe Leroy wrote:
> At the time being, we have PPC_RAW_PLXVP() and PPC_RAW_PSTXVP() which
> provide a 64 bits value, and then it gets split by open coding to
> format it into a 'struct ppc_inst' instruction.
>
> Instead, define a PPC_RAW_xxx_P() and a PPC_RAW_xxx_S() to be used
> as is.
Applied to powerpc/next.
[01/12] powerpc: Rework PPC_RAW_xxx() macros for prefixed instructions
https://git.kernel.org/powerpc/c/148a047602462ab04bff20f3529a255b0439d3df
[02/12] powerpc/opcodes: Add shorter macros for registers for use with PPC_RAW_xx()
https://git.kernel.org/powerpc/c/07cd18320ed816dec8ff6f58a2d8b33294dcceba
[03/12] powerpc/lib/code-patching: Use PPC_RAW_() macros
https://git.kernel.org/powerpc/c/8804d5beef9189fd2eae5aee14e1628436742e02
[04/12] powerpc/signal: Use PPC_RAW_xx() macros
https://git.kernel.org/powerpc/c/1c9debbc2eb5391277ae6aa7d95f821e0c28613d
[05/12] powerpc/modules: Use PPC_RAW_xx() macros
https://git.kernel.org/powerpc/c/47b04699d0709f5ff12a8aa0b3050a6246eb570e
[06/12] powerpc/security: Use PPC_RAW_BLR() and PPC_RAW_NOP()
https://git.kernel.org/powerpc/c/e7304597560176d8755e2ae4abb599d0c4efe4f2
[07/12] powerpc/ftrace: Use PPC_RAW_MFLR() and PPC_RAW_NOP()
https://git.kernel.org/powerpc/c/5a03e1e9728edce8f87e3e0bad6d4cd66329b129
[08/12] powerpc/ebpf64: Use PPC_RAW_MFLR()
https://git.kernel.org/powerpc/c/e08021f8dbd256f480b7e172aa4e894219c901f2
[09/12] powerpc/ebpf32: Use _Rx macros instead of __REG_Rx ones
https://git.kernel.org/powerpc/c/e0ea08c0cacf9370e3fd3ee8bb7456c61e79db66
[10/12] powerpc/lib/feature-fixups: Use PPC_RAW_xxx() macros
https://git.kernel.org/powerpc/c/ef909ba954145e35c9e21352133e5e99c64ab3f4
[11/12] powerpc/traps: Start using PPC_RAW_xx() macros
https://git.kernel.org/powerpc/c/deefd0ae990a689089ea1e4f5ad41799d63d4fd9
[12/12] powerpc: Replace PPC_INST_NOP by PPC_RAW_NOP()
https://git.kernel.org/powerpc/c/f30becb5e9ec086257162f78be491c0920c616b7
cheers
^ permalink raw reply
* Re: [PATCH v2 00/12] powerpc: Cleanup use of 'struct ppc_inst'
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Christophe Leroy,
jniethe5, naveen.n.rao, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1621516826.git.christophe.leroy@csgroup.eu>
On Thu, 20 May 2021 13:50:37 +0000 (UTC), Christophe Leroy wrote:
> This series is a cleanup of the use of 'struct ppc_inst'.
>
> A confusion is made between internal representation of powerpc
> instructions with 'struct ppc_inst' and in-memory code which is
> and will always be an array of 'unsigned int'.
>
> This series cleans it up.
>
> [...]
Applied to powerpc/next.
[01/12] powerpc/inst: Fix sparse detection on get_user_instr()
https://git.kernel.org/powerpc/c/b3a9e523237013477bea914b7fbfbe420428b988
[02/12] powerpc/inst: Reduce casts in get_user_instr()
https://git.kernel.org/powerpc/c/9134806e149ebb214f122f0f84254096d3768bb2
[03/12] powerpc/inst: Improve readability of get_user_instr() and friends
https://git.kernel.org/powerpc/c/042e0860e1c1d60a0ab1ff3f16b7f420573133e0
[04/12] powerpc/inst: Avoid pointer dereferencing in ppc_inst_equal()
https://git.kernel.org/powerpc/c/036b5560bebc72c61d955ae0b115e8e69da8a563
[05/12] powerpc: Do not dereference code as 'struct ppc_inst' (uprobe, code-patching, feature-fixups)
https://git.kernel.org/powerpc/c/18c85964b10b7b78a5cb59a4959a5f82fdc77e4c
[06/12] powerpc/lib/code-patching: Make instr_is_branch_to_addr() static
https://git.kernel.org/powerpc/c/6c0d181daabcba286db9711eef8800b566fb1cce
[07/12] powerpc/lib/code-patching: Don't use struct 'ppc_inst' for runnable code in tests.
https://git.kernel.org/powerpc/c/e90a21ea801d1776d9a786ad02354fd3fe23ce09
[08/12] powerpc: Don't use 'struct ppc_inst' to reference instruction location
https://git.kernel.org/powerpc/c/69d4d6e5fd9f4e805280ad831932c3df7b9d7cc7
[09/12] powerpc/inst: Refactor PPC32 and PPC64 versions
https://git.kernel.org/powerpc/c/077c4dedef09796ade917459a5330e3940fb5860
[10/12] powerpc/optprobes: Minimise casts
https://git.kernel.org/powerpc/c/afd3287c8872142ec4298a2b77bd9077e2209c9c
[11/12] powerpc/optprobes: Compact code source a bit.
https://git.kernel.org/powerpc/c/f38adf86ce4fdae84904f420e175ce5806509c4c
[12/12] powerpc/optprobes: use PPC_RAW_ macros
https://git.kernel.org/powerpc/c/0e628ad2d60896de31148fba00cc73623b8c0aa1
cheers
^ permalink raw reply
* Re: [PATCH v2 00/12] powerpc: Optimise KUAP on book3s/32
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1622708530.git.christophe.leroy@csgroup.eu>
On Thu, 3 Jun 2021 08:41:35 +0000 (UTC), Christophe Leroy wrote:
> This series is a rework of KUAP on book3s/32.
>
> On book3s32, KUAP is heavier than on other platform because it can't
> be opened globaly at once, it must be done for each 256Mb segment.
>
> Instead of opening access to all necessary segments via a heavy logic,
> only open access to the segment matching the start of the range.
>
> [...]
Applied to powerpc/next.
[01/12] powerpc/32s: Move setup_{kuep/kuap}() into {kuep/kuap}.c
https://git.kernel.org/powerpc/c/91ec66719d4c5c0e7b4e32585b01881660d1bc53
[02/12] powerpc/32s: Refactor update of user segment registers
https://git.kernel.org/powerpc/c/91bb30822a2e1d7900f9f42e9e92647a9015f979
[03/12] powerpc/32s: move CTX_TO_VSID() into mmu-hash.h
https://git.kernel.org/powerpc/c/7235bb3593781ed022d0714a73c2c0d8eb8a835f
[04/12] powerpc/32s: Convert switch_mmu_context() to C
https://git.kernel.org/powerpc/c/863771a28e27dc9eaeaa88cea300370d032f0e0f
[05/12] powerpc/32s: Simplify calculation of segment register content
https://git.kernel.org/powerpc/c/882136fb2f5208a35ddad9205b20e5791edd4782
[06/12] powerpc/32s: Initialise KUAP and KUEP in C
https://git.kernel.org/powerpc/c/86f46f3432727933be82f64b739712a6edb9d704
[07/12] powerpc/32s: Allow disabling KUEP at boot time
https://git.kernel.org/powerpc/c/50d2f104cd9572af476579eae9aa1b38de602ec7
[08/12] powerpc/32s: Allow disabling KUAP at boot time
https://git.kernel.org/powerpc/c/6b4d630068b0c5cdd6d8e599182b131448e0cb06
[09/12] powerpc/32s: Rework Kernel Userspace Access Protection
https://git.kernel.org/powerpc/c/16132529cee586ee9a058bb33cfbdcb5d884f6b3
[10/12] powerpc/32s: Activate KUAP and KUEP by default
https://git.kernel.org/powerpc/c/9f5bd8f1471d7498c934c0a686fd0997cf872653
[11/12] powerpc/kuap: Remove KUAP_CURRENT_XXX
https://git.kernel.org/powerpc/c/d008f8f8a0c3efe4fe1008a797f9497ea5965e27
[12/12] powerpc/kuap: Remove to/from/size parameters of prevent_user_access()
https://git.kernel.org/powerpc/c/cb2f1fb205cc20695fcaef84baf80d9d3e54c88b
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/8xx: Allow disabling KUAP at boot time
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <3dca510ce555335261a47c4799167da698f569c0.1622782111.git.christophe.leroy@csgroup.eu>
On Fri, 4 Jun 2021 04:49:25 +0000 (UTC), Christophe Leroy wrote:
> PPC64 uses MMU features to enable/disable KUAP at boot time.
> But feature fixups are applied way too early on PPC32.
>
> But since commit c16728835eec ("powerpc/32: Manage KUAP in C"),
> all KUAP is in C so it is now possible to use static branches.
Applied to powerpc/next.
[1/1] powerpc/8xx: Allow disabling KUAP at boot time
https://git.kernel.org/powerpc/c/f6025a140ba8dcabdfb8a1e27ddaf44821700dce
cheers
^ permalink raw reply
* Re: [PATCH v3 1/6] powerpc/nohash: Refactor update of BDI2000 pointers in switch_mmu_context()
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4c54997edd3548fa54717915e7c6ebaf60f208c0.1622712515.git.christophe.leroy@csgroup.eu>
On Thu, 3 Jun 2021 09:29:02 +0000 (UTC), Christophe Leroy wrote:
> Instead of duplicating the update of BDI2000 pointers in
> set_context(), do it directly from switch_mmu_context().
Applied to powerpc/next.
[1/6] powerpc/nohash: Refactor update of BDI2000 pointers in switch_mmu_context()
https://git.kernel.org/powerpc/c/25910260ff69fa0c37e26541aac4e8f978e1f17f
[2/6] powerpc/nohash: Convert set_context() to C
https://git.kernel.org/powerpc/c/a56ab7c7290f5922363d1ee11bbafc4da2b9bf51
[3/6] powerpc/nohash: Remove CONFIG_SMP #ifdefery in mmu_context.h
https://git.kernel.org/powerpc/c/c13066e53aabd8f268f051d267270765e10343aa
[4/6] powerpc/nohash: Remove DEBUG_MAP_CONSISTENCY
https://git.kernel.org/powerpc/c/dac3db1edf8b4c75859f07789f577322f2a51e3a
[5/6] powerpc/nohash: Remove DEBUG_CLAMP_LAST_CONTEXT
https://git.kernel.org/powerpc/c/a36c0faf3dbc429d5ddcb941afe38dd6fe6c5901
[6/6] powerpc/nohash: Remove DEBUG_HARDER
https://git.kernel.org/powerpc/c/e2c043163d44f7b3a9e65d9161af72b647b18451
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: make stack walking KASAN-safe
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev; +Cc: Naveen N . Rao
In-Reply-To: <20210614120907.1952321-1-dja@axtens.net>
On Mon, 14 Jun 2021 22:09:07 +1000, Daniel Axtens wrote:
> Make our stack-walking code KASAN-safe by using __no_sanitize_address.
> Generic code, arm64, s390 and x86 all make accesses unchecked for similar
> sorts of reasons: when unwinding a stack, we might touch memory that KASAN
> has marked as being out-of-bounds. In ppc64 KASAN development, I hit this
> sometimes when checking for an exception frame - because we're checking
> an arbitrary offset into the stack frame.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: make stack walking KASAN-safe
https://git.kernel.org/powerpc/c/b112fb913b5b5705db22efa90ec60f42518934af
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/tau: Remove superfluous parameter in alloc_workqueue() call
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Finn Thain, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a1456e8bbd33ef702e3ff6f14b1bf3919241c62b.1623398307.git.fthain@linux-m68k.org>
On Fri, 11 Jun 2021 17:58:27 +1000, Finn Thain wrote:
> This avoids an (optional) compiler warning:
>
> arch/powerpc/kernel/tau_6xx.c: In function 'TAU_init':
> arch/powerpc/kernel/tau_6xx.c:204:30: error: too many arguments for format [-Werror=format-extra-args]
> tau_workq = alloc_workqueue("tau", WQ_UNBOUND, 1, 0);
Applied to powerpc/next.
[1/1] powerpc/tau: Remove superfluous parameter in alloc_workqueue() call
https://git.kernel.org/powerpc/c/ddf4a7bcd09439e82c4d6f959f4ff6c53f07466f
cheers
^ permalink raw reply
* Re: [PATCH v2 0/2] PS3 Updates
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Geoff Levand, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <cover.1622822173.git.geoff@infradead.org>
On Fri, 04 Jun 2021 15:58:25 +0000, Geoff Levand wrote:
> I've rebased the V1 patches to v5.13-rc4, and moved the firmware version export
> from procfs to sysfs/firmware.
>
> Please consider.
>
> -Geoff
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/ps3: Add firmware version to sysfs
https://git.kernel.org/powerpc/c/07e2d6cf91079ca01db7fb989a02edd8009dcacd
cheers
^ permalink raw reply
* Re: [PATCH v2 0/3] DMA fixes for PS3 device drivers
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Geoff Levand, Michael Ellerman
Cc: Jakub Kicinski, linuxppc-dev, David S. Miller, netdev
In-Reply-To: <cover.1622746428.git.geoff@infradead.org>
On Thu, 03 Jun 2021 19:16:56 +0000, Geoff Levand wrote:
> This is a set of patches that fix various DMA related problems in the PS3
> device drivers, and add better error checking and improved message logging.
>
> Changes from V1:
> Split the V1 series into two, one series with powerpc changes, and one series
> with gelic network driver changes.
>
> [...]
Applied to powerpc/next.
[1/3] powerpc/ps3: Add CONFIG_PS3_VERBOSE_RESULT option
https://git.kernel.org/powerpc/c/6caebff168235b6102e5dc57cb95a2374301720a
[2/3] powerpc/ps3: Warn on PS3 device errors
https://git.kernel.org/powerpc/c/472b440fd26822c645befe459172dafdc2d225de
[3/3] powerpc/ps3: Add dma_mask to ps3_dma_region
https://git.kernel.org/powerpc/c/9733862e50fdba55e7f1554e4286fcc5302ff28e
cheers
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/ps3: Re-align DTB in image
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Geoff Levand, Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <245897ed65e402686a4b114ba618e935cb5c6506.1622822173.git.geoff@infradead.org>
On Fri, 04 Jun 2021 15:58:25 +0000, Geoff Levand wrote:
> Change the PS3 linker script to align the DTB at 8 bytes,
> the same alignment as that of the of the 'generic' powerpc
> linker script.
Applied to powerpc/next.
[2/2] powerpc/ps3: Re-align DTB in image
https://git.kernel.org/powerpc/c/ff4a825e4a24cdf7f840461ced6283bf865ab7be
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc/spider-pci: Remove set but not used variable 'val'
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: linuxppc-dev, paulus, arnd, mpe, benh, linux-kernel, Baokun Li
Cc: yangjihong1, yuehaibing, weiyongjun1, yukuai3
In-Reply-To: <20210601085319.140461-1-libaokun1@huawei.com>
On Tue, 1 Jun 2021 16:53:19 +0800, Baokun Li wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> arch/powerpc/platforms/cell/spider-pci.c: In function 'spiderpci_io_flush':
> arch/powerpc/platforms/cell/spider-pci.c:28:6: warning:
> variable ‘val’ set but not used [-Wunused-but-set-variable]
>
> It never used since introduction.
Applied to powerpc/next.
[1/1] powerpc/spider-pci: Remove set but not used variable 'val'
https://git.kernel.org/powerpc/c/f377f7da26d2af87e2ddc39190546f62ecdb2bd8
cheers
^ permalink raw reply
* Re: [PATCH -next] powerpc/spufs: disp: Remove set but not used variable 'dummy'
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: linuxppc-dev, jk, paulus, arnd, mpe, benh, linux-kernel,
Baokun Li
Cc: yangjihong1, yuehaibing, weiyongjun1, yukuai3
In-Reply-To: <20210601085127.139598-1-libaokun1@huawei.com>
On Tue, 1 Jun 2021 16:51:27 +0800, Baokun Li wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppu_mb_stat':
> arch/powerpc/platforms/cell/spufs/switch.c:1660:6: warning:
> variable ‘dummy’ set but not used [-Wunused-but-set-variable]
>
> arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppuint_mb_stat':
> arch/powerpc/platforms/cell/spufs/switch.c:1675:6: warning:
> variable ‘dummy’ set but not used [-Wunused-but-set-variable]
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/spufs: disp: Remove set but not used variable 'dummy'
https://git.kernel.org/powerpc/c/911bacda4658129bee039dc90fc0c3f193ee2695
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/signal64: Don't read sigaction arguments back from user memory
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman; +Cc: cmr
In-Reply-To: <20210610072949.3198522-1-mpe@ellerman.id.au>
On Thu, 10 Jun 2021 17:29:49 +1000, Michael Ellerman wrote:
> When delivering a signal to a sigaction style handler (SA_SIGINFO), we
> pass pointers to the siginfo and ucontext via r4 and r5.
>
> Currently we populate the values in those registers by reading the
> pointers out of the sigframe in user memory, even though the values in
> user memory were written by the kernel just prior:
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/signal64: Don't read sigaction arguments back from user memory
https://git.kernel.org/powerpc/c/a3309226454a7e76d76251579c1183787694f303
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/barrier: Avoid collision with clang's __lwsync macro
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: Nathan Chancellor, Michael Ellerman
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20210528182752.1852002-1-nathan@kernel.org>
On Fri, 28 May 2021 11:27:52 -0700, Nathan Chancellor wrote:
> A change in clang 13 results in the __lwsync macro being defined as
> __builtin_ppc_lwsync, which emits 'lwsync' or 'msync' depending on what
> the target supports. This breaks the build because of -Werror in
> arch/powerpc, along with thousands of warnings:
>
> In file included from arch/powerpc/kernel/pmc.c:12:
> In file included from include/linux/bug.h:5:
> In file included from arch/powerpc/include/asm/bug.h:109:
> In file included from include/asm-generic/bug.h:20:
> In file included from include/linux/kernel.h:12:
> In file included from include/linux/bitops.h:32:
> In file included from arch/powerpc/include/asm/bitops.h:62:
> arch/powerpc/include/asm/barrier.h:49:9: error: '__lwsync' macro redefined [-Werror,-Wmacro-redefined]
> #define __lwsync() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory")
> ^
> <built-in>:308:9: note: previous definition is here
> #define __lwsync __builtin_ppc_lwsync
> ^
> 1 error generated.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/barrier: Avoid collision with clang's __lwsync macro
https://git.kernel.org/powerpc/c/015d98149b326e0f1f02e44413112ca8b4330543
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: 52xx: add fallthrough in mpc52xx_wdt_ioctl()
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: paulus, trix, mpe, benh, agust; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20210601190200.2637776-1-trix@redhat.com>
On Tue, 1 Jun 2021 12:02:00 -0700, trix@redhat.com wrote:
> With gcc 10.3, there is this compiler error
> compiler.h:56:26: error: this statement may
> fall through [-Werror=implicit-fallthrough=]
>
> mpc52xx_gpt.c:586:2: note: here
> 586 | case WDIOC_GETTIMEOUT:
> | ^~~~
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: 52xx: add fallthrough in mpc52xx_wdt_ioctl()
https://git.kernel.org/powerpc/c/b629f6c0ab8668a186fda2627296d0cbcc45a368
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Remove the repeated declaration
From: Michael Ellerman @ 2021-06-18 3:51 UTC (permalink / raw)
To: linuxppc-dev, Shaokun Zhang
In-Reply-To: <1622529385-5938-1-git-send-email-zhangshaokun@hisilicon.com>
On Tue, 1 Jun 2021 14:36:25 +0800, Shaokun Zhang wrote:
> Function 'event_ebb_init' and 'event_leader_ebb_init' are declared
> twice in the header file, so remove the repeated declaration.
Applied to powerpc/next.
[1/1] selftests/powerpc: Remove the repeated declaration
https://git.kernel.org/powerpc/c/8f6a54bcaf62a791a7bceccc093497f7f53e2e26
cheers
^ permalink raw reply
* [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence
From: Wesley Sheng @ 2021-06-18 6:04 UTC (permalink / raw)
To: linasvepstas, ruscur, oohall, bhelgaas, corbet, linux-pci,
linuxppc-dev, linux-doc, linux-kernel
Cc: Wesley Sheng, wesleyshenggit
Reset_link() callback function was called before mmio_enabled() in
pcie_do_recovery() function actually, so rearrange the general
sequence betwen step 2 and step 3 accordingly.
Signed-off-by: Wesley Sheng <wesley.sheng@amd.com>
---
Documentation/PCI/pci-error-recovery.rst | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
index 187f43a03200..ac6a8729ef28 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -184,7 +184,14 @@ is STEP 6 (Permanent Failure).
and prints an error to syslog. A reboot is then required to
get the device working again.
-STEP 2: MMIO Enabled
+STEP 2: Link Reset
+------------------
+The platform resets the link. This is a PCI-Express specific step
+and is done whenever a fatal error has been detected that can be
+"solved" by resetting the link.
+
+
+STEP 3: MMIO Enabled
--------------------
The platform re-enables MMIO to the device (but typically not the
DMA), and then calls the mmio_enabled() callback on all affected
@@ -197,8 +204,8 @@ information, if any, and eventually do things like trigger a device local
reset or some such, but not restart operations. This callback is made if
all drivers on a segment agree that they can try to recover and if no automatic
link reset was performed by the HW. If the platform can't just re-enable IOs
-without a slot reset or a link reset, it will not call this callback, and
-instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+without a slot reset, it will not call this callback, and
+instead will have gone directly or STEP 4 (Slot Reset)
.. note::
@@ -210,7 +217,7 @@ instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
such an error might cause IOs to be re-blocked for the whole
segment, and thus invalidate the recovery that other devices
on the same segment might have done, forcing the whole segment
- into one of the next states, that is, link reset or slot reset.
+ into next states, that is, slot reset.
The driver should return one of the following result codes:
- PCI_ERS_RESULT_RECOVERED
@@ -233,17 +240,11 @@ The driver should return one of the following result codes:
The next step taken depends on the results returned by the drivers.
If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
-proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
+proceeds to STEP 5 (Resume Operations).
If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
proceeds to STEP 4 (Slot Reset)
-STEP 3: Link Reset
-------------------
-The platform resets the link. This is a PCI-Express specific step
-and is done whenever a fatal error has been detected that can be
-"solved" by resetting the link.
-
STEP 4: Slot Reset
------------------
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v13 01/12] swiotlb: Refactor swiotlb init functions
From: Claire Chang @ 2021-06-18 6:25 UTC (permalink / raw)
To: Stefano Stabellini
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, Nicolas Boichat, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Christoph Hellwig, Bartosz Golaszewski,
bskeggs, linux-pci, xen-devel, Thierry Reding, intel-gfx,
matthew.auld, linux-devicetree, Jianxiong Gao, Daniel Vetter,
Will Deacon, Konrad Rzeszutek Wilk, maarten.lankhorst, airlied,
Dan Williams, linuxppc-dev, jani.nikula, Rob Herring,
rodrigo.vivi, Bjorn Helgaas, boris.ostrovsky, Andy Shevchenko,
jgross, Greg KH, Randy Dunlap, lkml, Tomasz Figa,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Robin Murphy, bauerman
In-Reply-To: <alpine.DEB.2.21.2106171434480.24906@sstabellini-ThinkPad-T480s>
On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
<sstabellini@kernel.org> wrote:
>
> On Thu, 17 Jun 2021, Claire Chang wrote:
> > Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> > initialization to make the code reusable.
> >
> > Signed-off-by: Claire Chang <tientzu@chromium.org>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Tested-by: Stefano Stabellini <sstabellini@kernel.org>
> > Tested-by: Will Deacon <will@kernel.org>
> > ---
> > kernel/dma/swiotlb.c | 50 ++++++++++++++++++++++----------------------
> > 1 file changed, 25 insertions(+), 25 deletions(-)
> >
> > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > index 52e2ac526757..47bb2a766798 100644
> > --- a/kernel/dma/swiotlb.c
> > +++ b/kernel/dma/swiotlb.c
> > @@ -168,9 +168,28 @@ void __init swiotlb_update_mem_attributes(void)
> > memset(vaddr, 0, bytes);
> > }
> >
> > -int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
> > +static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
> > + unsigned long nslabs, bool late_alloc)
> > {
> > + void *vaddr = phys_to_virt(start);
> > unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> > +
> > + mem->nslabs = nslabs;
> > + mem->start = start;
> > + mem->end = mem->start + bytes;
> > + mem->index = 0;
> > + mem->late_alloc = late_alloc;
> > + spin_lock_init(&mem->lock);
> > + for (i = 0; i < mem->nslabs; i++) {
> > + mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > + mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > + mem->slots[i].alloc_size = 0;
> > + }
> > + memset(vaddr, 0, bytes);
> > +}
> > +
> > +int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
> > +{
> > struct io_tlb_mem *mem;
> > size_t alloc_size;
> >
> > @@ -186,16 +205,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
> > if (!mem)
> > panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
> > __func__, alloc_size, PAGE_SIZE);
> > - mem->nslabs = nslabs;
> > - mem->start = __pa(tlb);
> > - mem->end = mem->start + bytes;
> > - mem->index = 0;
> > - spin_lock_init(&mem->lock);
> > - for (i = 0; i < mem->nslabs; i++) {
> > - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > - mem->slots[i].alloc_size = 0;
> > - }
> > +
> > + swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
> >
> > io_tlb_default_mem = mem;
> > if (verbose)
> > @@ -282,8 +293,8 @@ swiotlb_late_init_with_default_size(size_t default_size)
> > int
> > swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
> > {
> > - unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
> > struct io_tlb_mem *mem;
> > + unsigned long bytes = nslabs << IO_TLB_SHIFT;
> >
> > if (swiotlb_force == SWIOTLB_NO_FORCE)
> > return 0;
> > @@ -297,20 +308,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
> > if (!mem)
> > return -ENOMEM;
> >
> > - mem->nslabs = nslabs;
> > - mem->start = virt_to_phys(tlb);
> > - mem->end = mem->start + bytes;
> > - mem->index = 0;
> > - mem->late_alloc = 1;
> > - spin_lock_init(&mem->lock);
> > - for (i = 0; i < mem->nslabs; i++) {
> > - mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
> > - mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
> > - mem->slots[i].alloc_size = 0;
> > - }
> > -
> > + memset(mem, 0, sizeof(*mem));
> > + swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true);
> > set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
> > - memset(tlb, 0, bytes);
>
> This is good for swiotlb_late_init_with_tbl. However I have just noticed
> that mem could also be allocated from swiotlb_init_with_tbl, in which
> case the zeroing is missing. I think we need another memset in
> swiotlb_init_with_tbl as well. Or maybe it could be better to have a
> single memset at the beginning of swiotlb_init_io_tlb_mem instead. Up to
> you.
swiotlb_init_with_tbl uses memblock_alloc to allocate the io_tlb_mem
and memblock_alloc[1] will do memset in memblock_alloc_try_nid[2], so
swiotlb_init_with_tbl is also good.
I'm happy to add the memset in swiotlb_init_io_tlb_mem if you think
it's clearer and safer.
[1] https://elixir.bootlin.com/linux/v5.13-rc6/source/include/linux/memblock.h#L407
[2] https://elixir.bootlin.com/linux/v5.13-rc6/source/mm/memblock.c#L1555
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence
From: Oliver O'Halloran @ 2021-06-18 7:21 UTC (permalink / raw)
To: Wesley Sheng
Cc: wesleyshenggit, Jonathan Corbet, linux-pci, linux-doc,
Linux Kernel Mailing List, Bjorn Helgaas, linasvepstas,
linuxppc-dev
In-Reply-To: <20210618060446.7969-1-wesley.sheng@amd.com>
On Fri, Jun 18, 2021 at 4:05 PM Wesley Sheng <wesley.sheng@amd.com> wrote:
>
> Reset_link() callback function was called before mmio_enabled() in
> pcie_do_recovery() function actually, so rearrange the general
> sequence betwen step 2 and step 3 accordingly.
I don't think this is true in all cases. If pcie_do_recovery() is
called with state==pci_channel_io_normal (i.e. non-fatal AER) the link
won't be reset. EEH (ppc PCI error recovery thing) also uses
.mmio_enabled() as described.
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/64s: Add DEBUG_PAGEALLOC for radix
From: Daniel Axtens @ 2021-06-18 7:28 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev; +Cc: Jordan Niethe, npiggin, aneesh.kumar
In-Reply-To: <20210517061658.194708-2-jniethe5@gmail.com>
Jordan Niethe <jniethe5@gmail.com> writes:
> There is support for DEBUG_PAGEALLOC on hash but not on radix.
> Add support on radix.
Somewhat off-topic but I wonder at what point we can drop the weird !PPC
condition in mm/Kconfig.debug:
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
depends on DEBUG_KERNEL
depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
I can't figure out from git history why it exists or if it still serves
any function. Given that HIBERNATION isn't much use on Book3S systems it
probably never matters, it just bugs me a bit.
Again, nothing that has to block this series, just maybe something to
follow up at some vague and undefined point in the future!
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index a666d561b44d..b89482aed82a 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -812,6 +822,15 @@ static inline bool check_pte_access(unsigned long access, unsigned long ptev)
> * Generic functions with hash/radix callbacks
> */
>
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +static inline void __kernel_map_pages(struct page *page, int numpages, int enable)
> +{
> + if (radix_enabled())
> + radix__kernel_map_pages(page, numpages, enable);
> + hash__kernel_map_pages(page, numpages, enable);
Does this require an else? On radix we will call both radix__ and
hash__kernel_map_pages.
I notice we call both hash__ and radix__ in map_kernel_page under radix,
so maybe this makes sense?
I don't fully understand the mechanism by which memory removal works: it
looks like on radix you mark the page as 'absent', which I think is
enough? Then you fall through to the hash code here:
for (i = 0; i < numpages; i++, page++) {
vaddr = (unsigned long)page_address(page);
lmi = __pa(vaddr) >> PAGE_SHIFT;
if (lmi >= linear_map_hash_count)
continue;
I think linear_map_hash_count will be zero unless it gets inited to a
non-zero value in htab_initialize(). I am fairly sure htab_initialize()
doesn't get called for a radix MMU. In that case you'll just `continue;`
out of every iteration of the loop, which would explain why nothing
weird would happen on radix.
Have I missed something here?
The rest of the patch looks good to me.
Kind regards,
Daniel
^ permalink raw reply
* Re: [PATCH v2 5/9] powerpc/microwatt: Use standard 16550 UART for console
From: Nicholas Piggin @ 2021-06-18 7:40 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackerras
In-Reply-To: <YMwXGCTzedpQje7r@thinks.paulus.ozlabs.org>
Excerpts from Paul Mackerras's message of June 18, 2021 1:46 pm:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> This adds support to the Microwatt platform to use the standard
> 16550-style UART which available in the standalone Microwatt FPGA.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> ---
> arch/powerpc/boot/dts/microwatt.dts | 27 ++++++++++++----
> arch/powerpc/kernel/udbg_16550.c | 39 ++++++++++++++++++++++++
> arch/powerpc/platforms/microwatt/Kconfig | 1 +
> arch/powerpc/platforms/microwatt/setup.c | 2 ++
> 4 files changed, 63 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/microwatt.dts b/arch/powerpc/boot/dts/microwatt.dts
> index 04e5dd92270e..974abbdda249 100644
> --- a/arch/powerpc/boot/dts/microwatt.dts
> +++ b/arch/powerpc/boot/dts/microwatt.dts
> @@ -6,6 +6,10 @@ / {
> model-name = "microwatt";
> compatible = "microwatt-soc";
>
> + aliases {
> + serial0 = &UART0;
> + };
> +
> reserved-memory {
> #size-cells = <0x02>;
> #address-cells = <0x02>;
> @@ -89,12 +93,6 @@ PowerPC,Microwatt@0 {
> };
> };
>
> - chosen {
> - bootargs = "";
> - ibm,architecture-vec-5 = [19 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> - 00 00 00 00 00 00 00 00 40 00 40];
> - };
> -
> soc@c0000000 {
> compatible = "simple-bus";
> #address-cells = <1>;
> @@ -119,5 +117,22 @@ ICS: interrupt-controller@5000 {
> #interrupt-cells = <2>;
> };
>
> + UART0: serial@2000 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x2000 0x8>;
> + clock-frequency = <100000000>;
> + current-speed = <115200>;
> + reg-shift = <2>;
> + fifo-size = <16>;
> + interrupts = <0x10 0x1>;
> + };
> + };
> +
> + chosen {
> + bootargs = "";
> + ibm,architecture-vec-5 = [19 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00
> + 00 00 00 00 00 00 00 00 40 00 40];
> + stdout-path = &UART0;
> };
> };
> diff --git a/arch/powerpc/kernel/udbg_16550.c b/arch/powerpc/kernel/udbg_16550.c
> index 9356b60d6030..8513aa49614e 100644
> --- a/arch/powerpc/kernel/udbg_16550.c
> +++ b/arch/powerpc/kernel/udbg_16550.c
> @@ -296,3 +296,42 @@ void __init udbg_init_40x_realmode(void)
> }
>
> #endif /* CONFIG_PPC_EARLY_DEBUG_40x */
> +
> +#ifdef CONFIG_PPC_EARLY_DEBUG_MICROWATT
> +
> +#define UDBG_UART_MW_ADDR ((void __iomem *)0xc0002000)
> +
> +static u8 udbg_uart_in_isa300_rm(unsigned int reg)
> +{
> + uint64_t msr = mfmsr();
> + uint8_t c;
> +
> + mtmsr(msr & ~(MSR_EE|MSR_DR));
> + isync();
> + eieio();
> + c = __raw_rm_readb(UDBG_UART_MW_ADDR + (reg << 2));
> + mtmsr(msr);
> + isync();
> + return c;
> +}
Why is realmode required? No cache inhibited mappings yet?
mtmsrd with L=0 is defined to be context synchronizing in isa 3, so I
don't think the isync would be required. There is a bit of code around
arch/powerpc that does this, maybe it used to be needed or some other
implementations needed it?
That's just for my curiosity, it doesn't really hurt to have them
there.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/64s: Remove unneeded #ifdef CONFIG_DEBUG_PAGEALLOC in hash_utils
From: Daniel Axtens @ 2021-06-18 7:49 UTC (permalink / raw)
To: Jordan Niethe, linuxppc-dev, christophe.leroy
Cc: Jordan Niethe, npiggin, aneesh.kumar
In-Reply-To: <20210517061658.194708-3-jniethe5@gmail.com>
Hi Jordan and Christophe,
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -126,11 +126,8 @@ EXPORT_SYMBOL_GPL(mmu_slb_size);
> #ifdef CONFIG_PPC_64K_PAGES
> int mmu_ci_restrictions;
> #endif
> -#ifdef CONFIG_DEBUG_PAGEALLOC
> static u8 *linear_map_hash_slots;
> static unsigned long linear_map_hash_count;
> -static DEFINE_SPINLOCK(linear_map_hash_lock);
> -#endif /* CONFIG_DEBUG_PAGEALLOC */
> struct mmu_hash_ops mmu_hash_ops;
> EXPORT_SYMBOL(mmu_hash_ops);
>
> @@ -1944,6 +1937,8 @@ long hpte_insert_repeating(unsigned long hash, unsigned long vpn,
> }
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
> +static DEFINE_SPINLOCK(linear_map_hash_lock);
> +
I had some trouble figuring out why the spinlock has to be in the
ifdef. A bit of investigation suggests that it's only used in functions
that are only defined under CONFIG_DEBUG_PAGEALLOC - unlike the other
variables. So that makes sense.
While I was poking around, I noticed that linear_map_hash_slots is
manipulated under linear_map_hash_lock in kernel_(un)map_linear_page but
is manipulated outside the lock in htab_bolt_mapping(). Is that OK? (I
don't know when htab_bolt_mapping is called, it's possible it's only
called at times where nothing else could be happing to that array.)
Kind regards,
Daniel
> static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
> {
> unsigned long hash;
> --
> 2.25.1
^ permalink raw reply
* Re: [PATCH v6 12/17] powerpc/pseries/vas: Integrate API with open/close windows
From: Haren Myneni @ 2021-06-18 7:49 UTC (permalink / raw)
To: Nicholas Piggin, herbert, linux-crypto, linuxppc-dev, mpe
In-Reply-To: <1623971609.844odc55aw.astroid@bobo.none>
On Fri, 2021-06-18 at 09:22 +1000, Nicholas Piggin wrote:
> Excerpts from Haren Myneni's message of June 18, 2021 6:36 am:
> > This patch adds VAS window allocatioa/close with the corresponding
> > hcalls. Also changes to integrate with the existing user space VAS
> > API and provide register/unregister functions to NX pseries driver.
> >
> > The driver register function is used to create the user space
> > interface (/dev/crypto/nx-gzip) and unregister to remove this
> > entry.
> >
> > The user space process opens this device node and makes an ioctl
> > to allocate VAS window. The close interface is used to deallocate
> > window.
> >
> > Signed-off-by: Haren Myneni <haren@linux.ibm.com>
>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>
> Unless there is some significant performance reason it might be
> simplest
> to take the mutex for the duration of the allocate and frees rather
> than
> taking it several times, covering the atomic with the lock instead.
>
> You have a big lock, might as well use it and not have to wonder what
> if
> things race here or there.
Using mutex to protect allocate/deallocate window and setup/free IRQ,
also to protect updating the list. We do not need lock for modify
window hcall and other things. Hence taking mutex several times. Also
used atomic for counters (used_lpar_creds) which can be exported in
sysfs (this patch will be added later in next enhancement seris).
Genarlly applications open window initially, do continuous copy/paste
operations and close window later. But possible that the library /
application to open/close window for each request. Also may be opening
or closing multiple windows (say 1000 depends on cores on the system)
at the same time. These cases may affect the application performance.
Thanks
Haren
>
> But don't rework that now, maybe just something to consider for
> later.
>
> Thanks,
> Nick
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox