* Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
From: Guenter Roeck @ 2021-07-02 13:48 UTC (permalink / raw)
To: Will Deacon, Robin Murphy
Cc: heikki.krogerus, linux-devicetree, peterz, linux-pci, dri-devel,
chris, grant.likely, paulus, Frank Rowand, mingo, jxgao,
sstabellini, Saravana Kannan, Joerg Roedel, Rafael J . Wysocki,
Christoph Hellwig, Bartosz Golaszewski, bskeggs, xen-devel,
Marek Szyprowski, matthew.auld, Nicolas Boichat, thomas.hellstrom,
Konrad Rzeszutek Wilk, intel-gfx, Dan Williams, Rob Herring,
rodrigo.vivi, bhelgaas, Claire Chang, boris.ostrovsky,
Andy Shevchenko, jgross, airlied, Thierry Reding, Greg KH,
Randy Dunlap, quic_qiancai, lkml, tfiga,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
thomas.lendacky, linuxppc-dev, bauerman
In-Reply-To: <20210702131829.GA11132@willie-the-truck>
On 7/2/21 6:18 AM, Will Deacon wrote:
> On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
>> On 2021-07-02 04:08, Guenter Roeck wrote:
>>> On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
>>>> If a device is not behind an IOMMU, we look up the device node and set
>>>> up the restricted DMA when the restricted-dma-pool is presented.
>>>>
>>>> Signed-off-by: Claire Chang <tientzu@chromium.org>
>>>> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
>>>> Tested-by: Will Deacon <will@kernel.org>
>>>
>>> With this patch in place, all sparc and sparc64 qemu emulations
>>> fail to boot. Symptom is that the root file system is not found.
>>> Reverting this patch fixes the problem. Bisect log is attached.
>>
>> Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
>> returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
>> stub. That should probably be returning 0 instead, since either way it's not
>> an error condition for it to simply do nothing.
>
> Something like below?
>
Yes, that does the trick.
> Will
>
> --->8
>
>>From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
> From: Will Deacon <will@kernel.org>
> Date: Fri, 2 Jul 2021 14:13:28 +0100
> Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
> !OF_ADDRESS
>
> When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
> and breaks the boot for sparc[64] machines. Return 0 instead, since the
> function is essentially a glorified NOP in this configuration.
>
> Cc: Claire Chang <tientzu@chromium.org>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Suggested-by: Robin Murphy <robin.murphy@arm.com>
> Link: https://lore.kernel.org/r/20210702030807.GA2685166@roeck-us.net
> Signed-off-by: Will Deacon <will@kernel.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/of/of_private.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
> index 8fde97565d11..34dd548c5eac 100644
> --- a/drivers/of/of_private.h
> +++ b/drivers/of/of_private.h
> @@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
> static inline int of_dma_set_restricted_buffer(struct device *dev,
> struct device_node *np)
> {
> - return -ENODEV;
> + /* Do nothing, successfully. */
> + return 0;
> }
> #endif
>
>
^ permalink raw reply
* Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
From: Will Deacon @ 2021-07-02 13:18 UTC (permalink / raw)
To: Robin Murphy
Cc: heikki.krogerus, linux-devicetree, peterz, linux-pci, dri-devel,
chris, grant.likely, paulus, Frank Rowand, mingo, jxgao,
sstabellini, Saravana Kannan, Joerg Roedel, Rafael J . Wysocki,
Christoph Hellwig, Bartosz Golaszewski, bskeggs, xen-devel,
Marek Szyprowski, Guenter Roeck, matthew.auld, Nicolas Boichat,
thomas.hellstrom, Konrad Rzeszutek Wilk, intel-gfx, Dan Williams,
Rob Herring, rodrigo.vivi, bhelgaas, Claire Chang,
boris.ostrovsky, Andy Shevchenko, jgross, airlied, Thierry Reding,
Greg KH, Randy Dunlap, quic_qiancai, lkml, tfiga,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
thomas.lendacky, linuxppc-dev, bauerman
In-Reply-To: <87ca3ada-22ed-f40c-0089-ca6fffc04f24@arm.com>
On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
> On 2021-07-02 04:08, Guenter Roeck wrote:
> > On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
> > > If a device is not behind an IOMMU, we look up the device node and set
> > > up the restricted DMA when the restricted-dma-pool is presented.
> > >
> > > Signed-off-by: Claire Chang <tientzu@chromium.org>
> > > Tested-by: Stefano Stabellini <sstabellini@kernel.org>
> > > Tested-by: Will Deacon <will@kernel.org>
> >
> > With this patch in place, all sparc and sparc64 qemu emulations
> > fail to boot. Symptom is that the root file system is not found.
> > Reverting this patch fixes the problem. Bisect log is attached.
>
> Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
> returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
> stub. That should probably be returning 0 instead, since either way it's not
> an error condition for it to simply do nothing.
Something like below?
Will
--->8
From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
From: Will Deacon <will@kernel.org>
Date: Fri, 2 Jul 2021 14:13:28 +0100
Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
!OF_ADDRESS
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang <tientzu@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20210702030807.GA2685166@roeck-us.net
Signed-off-by: Will Deacon <will@kernel.org>
---
drivers/of/of_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8fde97565d11..34dd548c5eac 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
static inline int of_dma_set_restricted_buffer(struct device *dev,
struct device_node *np)
{
- return -ENODEV;
+ /* Do nothing, successfully. */
+ return 0;
}
#endif
--
2.32.0.93.g670b81a890-goog
^ permalink raw reply related
* Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests
From: Theodore Ts'o @ 2021-07-02 13:13 UTC (permalink / raw)
To: Guoqing Jiang
Cc: Sachin Sant, jack, yi.zhang, linux-fsdevel, linux-ext4,
linuxppc-dev
In-Reply-To: <bf1c5b38-92f1-65db-e210-a97a199718ba@linux.dev>
On Fri, Jul 02, 2021 at 05:38:10PM +0800, Guoqing Jiang wrote:
>
>
> I guess the problem is j_jh_shrink_count was destroyed in ext4_put_super _>
> jbd2_journal_unregister_shrinker
> which is before the path ext4_put_super -> jbd2_journal_destroy ->
> jbd2_log_do_checkpoint to call
> percpu_counter_dec(&journal->j_jh_shrink_count).
>
> And since jbd2_journal_unregister_shrinker is already called inside
> jbd2_journal_destroy, does it make sense
> to do this?
>
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1176,7 +1176,6 @@ static void ext4_put_super(struct super_block *sb)
> ext4_unregister_sysfs(sb);
>
> if (sbi->s_journal) {
> - jbd2_journal_unregister_shrinker(sbi->s_journal);
> aborted = is_journal_aborted(sbi->s_journal);
> err = jbd2_journal_destroy(sbi->s_journal);
> sbi->s_journal = NULL;
Good catch. There's another place where we call
jbd2_journal_unregister_shrinker(), in the failure path for
ext4_fill_super().
- Ted
P.S. Whatever outgoing mailer you are using, it's not preserving TAB
characters correctly. You might want to look into that before trying
to submit a patch.
^ permalink raw reply
* Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
From: Robin Murphy @ 2021-07-02 11:39 UTC (permalink / raw)
To: Guenter Roeck, Claire Chang
Cc: heikki.krogerus, linux-devicetree, peterz, linux-pci, dri-devel,
chris, grant.likely, paulus, Frank Rowand, mingo, jxgao,
sstabellini, Saravana Kannan, Joerg Roedel, Rafael J . Wysocki,
Christoph Hellwig, Bartosz Golaszewski, bskeggs, xen-devel,
Marek Szyprowski, matthew.auld, Nicolas Boichat, thomas.hellstrom,
Will Deacon, Konrad Rzeszutek Wilk, intel-gfx, Dan Williams,
Rob Herring, rodrigo.vivi, bhelgaas, boris.ostrovsky,
Andy Shevchenko, jgross, airlied, Thierry Reding, Greg KH,
Randy Dunlap, quic_qiancai, lkml, tfiga,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
thomas.lendacky, linuxppc-dev, bauerman
In-Reply-To: <20210702030807.GA2685166@roeck-us.net>
On 2021-07-02 04:08, Guenter Roeck wrote:
> Hi,
>
> On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
>> If a device is not behind an IOMMU, we look up the device node and set
>> up the restricted DMA when the restricted-dma-pool is presented.
>>
>> Signed-off-by: Claire Chang <tientzu@chromium.org>
>> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
>> Tested-by: Will Deacon <will@kernel.org>
>
> With this patch in place, all sparc and sparc64 qemu emulations
> fail to boot. Symptom is that the root file system is not found.
> Reverting this patch fixes the problem. Bisect log is attached.
Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
stub. That should probably be returning 0 instead, since either way it's
not an error condition for it to simply do nothing.
Robin.
>
> Guenter
>
> ---
> # bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux-next specific files for 20210701
> # good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13
> git bisect start 'HEAD' 'v5.13'
> # bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch 'rdma/for-next'
> git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90
> # good: [46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4] Merge remote-tracking branch 'ipsec/master'
> git bisect good 46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4
> # good: [43ba6969cfb8185353a7a6fc79070f13b9e3d6d3] Merge remote-tracking branch 'clk/clk-next'
> git bisect good 43ba6969cfb8185353a7a6fc79070f13b9e3d6d3
> # good: [1ca5eddcf8dca1d6345471c6404e7364af0d7019] Merge remote-tracking branch 'fuse/for-next'
> git bisect good 1ca5eddcf8dca1d6345471c6404e7364af0d7019
> # good: [8f6d7b3248705920187263a4e7147b0752ec7dcf] Merge remote-tracking branch 'pci/next'
> git bisect good 8f6d7b3248705920187263a4e7147b0752ec7dcf
> # good: [df1885a755784da3ef285f36d9230c1d090ef186] RDMA/rtrs_clt: Alloc less memory with write path fast memory registration
> git bisect good df1885a755784da3ef285f36d9230c1d090ef186
> # good: [93d31efb58c8ad4a66bbedbc2d082df458c04e45] Merge remote-tracking branch 'cpufreq-arm/cpufreq/arm/linux-next'
> git bisect good 93d31efb58c8ad4a66bbedbc2d082df458c04e45
> # good: [46308965ae6fdc7c25deb2e8c048510ae51bbe66] RDMA/irdma: Check contents of user-space irdma_mem_reg_req object
> git bisect good 46308965ae6fdc7c25deb2e8c048510ae51bbe66
> # good: [6de7a1d006ea9db235492b288312838d6878385f] thermal/drivers/int340x/processor_thermal: Split enumeration and processing part
> git bisect good 6de7a1d006ea9db235492b288312838d6878385f
> # good: [081bec2577cda3d04f6559c60b6f4e2242853520] dt-bindings: of: Add restricted DMA pool
> git bisect good 081bec2577cda3d04f6559c60b6f4e2242853520
> # good: [bf95ac0bcd69979af146852f6a617a60285ebbc1] Merge remote-tracking branch 'thermal/thermal/linux-next'
> git bisect good bf95ac0bcd69979af146852f6a617a60285ebbc1
> # good: [3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc] RDMA/core: Always release restrack object
> git bisect good 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc
> # bad: [cff1f23fad6e0bd7d671acce0d15285c709f259c] Merge remote-tracking branch 'swiotlb/linux-next'
> git bisect bad cff1f23fad6e0bd7d671acce0d15285c709f259c
> # bad: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool
> git bisect bad b655006619b7bccd0dc1e055bd72de5d613e7b5c
> # first bad commit: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool
>
^ permalink raw reply
* Re: [PATCH] powerpc: Only build restart_table.c for 64s
From: Michael Ellerman @ 2021-07-02 10:59 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20210701125026.292224-1-mpe@ellerman.id.au>
On Thu, 1 Jul 2021 22:50:26 +1000, Michael Ellerman wrote:
> Commit 9b69d48c7516 ("powerpc/64e: remove implicit soft-masking and
> interrupt exit restart logic") limited the implicit soft masking and
> restart logic to 64-bit Book3S only. However we are still building
> restart_table.c for all 64-bit, ie. Book3E also.
>
> There's no need to build it for 64e, and it also causes missing
> prototype warnings for 64e builds, because the prototype is already
> behind an #ifdef PPC_BOOK3S_64.
Applied to powerpc/next.
[1/1] powerpc: Only build restart_table.c for 64s
https://git.kernel.org/powerpc/c/4ebbbaa4ce8524b853dd6febf0176a6efa3482d7
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/bpf: Fix detecting BPF atomic instructions
From: Jiri Olsa @ 2021-07-02 10:26 UTC (permalink / raw)
To: Naveen N. Rao
Cc: Daniel Borkmann, Brendan Jackman, bpf, linuxppc-dev,
Alexei Starovoitov
In-Reply-To: <4117b430ffaa8cd7af042496f87fd7539e4f17fd.1625145429.git.naveen.n.rao@linux.vnet.ibm.com>
On Thu, Jul 01, 2021 at 08:38:58PM +0530, Naveen N. Rao wrote:
> Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
> atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
> distinguish instructions based on the immediate field. Existing JIT
> implementations were updated to check for the immediate field and to
> reject programs utilizing anything more than BPF_ADD (such as BPF_FETCH)
> in the immediate field.
>
> However, the check added to powerpc64 JIT did not look at the correct
> BPF instruction. Due to this, such programs would be accepted and
> incorrectly JIT'ed resulting in soft lockups, as seen with the atomic
> bounds test. Fix this by looking at the correct immediate value.
>
> Fixes: 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other atomics in .imm")
> Reported-by: Jiri Olsa <jolsa@redhat.com>
> Tested-by: Jiri Olsa <jolsa@redhat.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> Hi Jiri,
> FYI: I made a small change in this patch -- using 'imm' directly, rather
> than insn[i].imm. I've still added your Tested-by since this shouldn't
> impact the fix in any way.
yep, it works nicely
thanks
jirka
>
> - Naveen
>
>
> arch/powerpc/net/bpf_jit_comp64.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index 5cad5b5a7e9774..de8595880feec6 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -667,7 +667,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> * BPF_STX ATOMIC (atomic ops)
> */
> case BPF_STX | BPF_ATOMIC | BPF_W:
> - if (insn->imm != BPF_ADD) {
> + if (imm != BPF_ADD) {
> pr_err_ratelimited(
> "eBPF filter atomic op code %02x (@%d) unsupported\n",
> code, i);
> @@ -689,7 +689,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, struct codegen_context *
> PPC_BCC_SHORT(COND_NE, tmp_idx);
> break;
> case BPF_STX | BPF_ATOMIC | BPF_DW:
> - if (insn->imm != BPF_ADD) {
> + if (imm != BPF_ADD) {
> pr_err_ratelimited(
> "eBPF filter atomic op code %02x (@%d) unsupported\n",
> code, i);
> --
> 2.31.1
>
^ permalink raw reply
* Re: [PATCH v2 3/4] powerpc: wii.dts: Expose the OTP on this platform
From: Jonathan Neuschäfer @ 2021-07-02 8:56 UTC (permalink / raw)
To: Emmanuel Gil Peyrot
Cc: devicetree, linux-kernel, Rob Herring, Srinivas Kandagatla,
Ash Logan, Paul Mackerras, linuxppc-dev, Jonathan Neuschäfer
In-Reply-To: <20210701195655.knbcikdga57a7epx@luna>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Thu, Jul 01, 2021 at 09:56:55PM +0200, Emmanuel Gil Peyrot wrote:
> On Sat, Jun 26, 2021 at 11:34:01PM +0000, Jonathan Neuschäfer wrote:
> > On Wed, May 19, 2021 at 11:50:43AM +0200, Emmanuel Gil Peyrot wrote:
[...]
> > > + otp@d8001ec {
> > > + compatible = "nintendo,hollywood-otp";
> > > + reg = <0x0d8001ec 0x8>;
> >
> > The OTP registers overlap with the previous node, control@d800100.
> > Not sure what's the best way to structure the devicetree in this case,
> > maybe something roughly like the following (untested, unverified):
> [snip]
>
> I couldn’t get this to work, but additionally it looks like it should
> start 0x100 earlier and contain pic1@d800030 and gpio@d8000c0, given
> https://wiibrew.org/wiki/Hardware/Hollywood_Registers
>
> Would it make sense, for the time being, to reduce the size of this
> control@d800100 device to the single register currently being used by
> arch/powerpc/platforms/embedded6xx/wii.c (0xd800194, used to reboot the
> system) and leave the refactor of restart + OTP + PIC + GPIO for a
> future series?
Makes sense to me!
Jonathan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests
From: Sachin Sant @ 2021-07-02 8:51 UTC (permalink / raw)
To: linux-ext4, linux-fsdevel; +Cc: jack, linuxppc-dev, yi.zhang
While running LTP tests (chdir01) against 5.13.0-next20210701 booted on a Power server,
following crash is encountered.
[ 3051.182992] ext2 filesystem being mounted at /var/tmp/avocado_oau90dri/ltp-W0cFB5HtCy/lKhal5/mntpoint supports timestamps until 2038 (0x7fffffff)
[ 3051.621341] EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
[ 3051.624645] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[ 3051.624682] ext3 filesystem being mounted at /var/tmp/avocado_oau90dri/ltp-W0cFB5HtCy/lKhal5/mntpoint supports timestamps until 2038 (0x7fffffff)
[ 3051.629026] Kernel attempted to read user page (13fda70000) - exploit attempt? (uid: 0)
[ 3051.629074] BUG: Unable to handle kernel data access on read at 0x13fda70000
[ 3051.629103] Faulting instruction address: 0xc0000000006fa5cc
[ 3051.629118] Oops: Kernel access of bad area, sig: 11 [#1]
[ 3051.629130] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 3051.629148] Modules linked in: vfat fat btrfs blake2b_generic xor zstd_compress raid6_pq xfs loop sctp ip6_udp_tunnel udp_tunnel libcrc32c rpadlpar_io rpaphp dm_mod bonding rfkill sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse [last unloaded: test_cpuidle_latency]
[ 3051.629270] CPU: 10 PID: 274044 Comm: chdir01 Tainted: G W OE 5.13.0-next-20210701 #1
[ 3051.629289] NIP: c0000000006fa5cc LR: c008000006949bc4 CTR: c0000000006fa5a0
[ 3051.629300] REGS: c000000f74de3660 TRAP: 0300 Tainted: G W OE (5.13.0-next-20210701)
[ 3051.629314] MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24000288 XER: 20040000
[ 3051.629342] CFAR: c008000006957564 DAR: 00000013fda70000 DSISR: 40000000 IRQMASK: 0
[ 3051.629342] GPR00: c008000006949bc4 c000000f74de3900 c0000000029bc800 c000000f88f0ab80
[ 3051.629342] GPR04: ffffffffffffffff 0000000000000020 0000000024000282 0000000000000000
[ 3051.629342] GPR08: c00000110628c828 0000000000000000 00000013fda70000 c008000006957550
[ 3051.629342] GPR12: c0000000006fa5a0 c0000013ffffbe80 0000000000000000 0000000000000000
[ 3051.629342] GPR16: 0000000000000000 0000000000000000 00000000100555f8 0000000010050d40
[ 3051.629342] GPR20: 0000000000000000 0000000010026188 0000000010026160 c000000f88f0ac08
[ 3051.629342] GPR24: 0000000000000000 c000000f88f0a920 0000000000000000 0000000000000002
[ 3051.629342] GPR28: c000000f88f0ac50 c000000f88f0a800 c000000fc5577d00 c000000f88f0ab80
[ 3051.629468] NIP [c0000000006fa5cc] percpu_counter_add_batch+0x2c/0xf0
[ 3051.629493] LR [c008000006949bc4] __jbd2_journal_remove_checkpoint+0x9c/0x280 [jbd2]
[ 3051.629526] Call Trace:
[ 3051.629532] [c000000f74de3900] [c000000f88f0a84c] 0xc000000f88f0a84c (unreliable)
[ 3051.629547] [c000000f74de3940] [c008000006949bc4] __jbd2_journal_remove_checkpoint+0x9c/0x280 [jbd2]
[ 3051.629577] [c000000f74de3980] [c008000006949eb4] jbd2_log_do_checkpoint+0x10c/0x630 [jbd2]
[ 3051.629605] [c000000f74de3a40] [c0080000069547dc] jbd2_journal_destroy+0x1b4/0x4e0 [jbd2]
[ 3051.629636] [c000000f74de3ad0] [c00800000735d72c] ext4_put_super+0xb4/0x560 [ext4]
[ 3051.629703] [c000000f74de3b60] [c000000000484d64] generic_shutdown_super+0xc4/0x1d0
[ 3051.629720] [c000000f74de3bd0] [c000000000484f48] kill_block_super+0x38/0x90
[ 3051.629736] [c000000f74de3c00] [c000000000485120] deactivate_locked_super+0x80/0x100
[ 3051.629752] [c000000f74de3c30] [c0000000004bec1c] cleanup_mnt+0x10c/0x1d0
[ 3051.629767] [c000000f74de3c80] [c000000000188b08] task_work_run+0xf8/0x170
[ 3051.629783] [c000000f74de3cd0] [c000000000021a24] do_notify_resume+0x434/0x480
[ 3051.629800] [c000000f74de3d80] [c000000000032910] interrupt_exit_user_prepare_main+0x1a0/0x260
[ 3051.629816] [c000000f74de3de0] [c000000000032d08] syscall_exit_prepare+0x68/0x150
[ 3051.629830] [c000000f74de3e10] [c00000000000c770] system_call_common+0x100/0x258
[ 3051.629846] --- interrupt: c00 at 0x7fffa2b92ffc
[ 3051.629855] NIP: 00007fffa2b92ffc LR: 00007fffa2b92fcc CTR: 0000000000000000
[ 3051.629867] REGS: c000000f74de3e80 TRAP: 0c00 Tainted: G W OE (5.13.0-next-20210701)
[ 3051.629880] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24000474 XER: 00000000
[ 3051.629908] IRQMASK: 0
[ 3051.629908] GPR00: 0000000000000034 00007fffc0242e20 00007fffa2c77100 0000000000000000
[ 3051.629908] GPR04: 0000000000000000 0000000000000078 0000000000000000 0000000000000020
[ 3051.629908] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 3051.629908] GPR12: 0000000000000000 00007fffa2d1a310 0000000000000000 0000000000000000
[ 3051.629908] GPR16: 0000000000000000 0000000000000000 00000000100555f8 0000000010050d40
[ 3051.629908] GPR20: 0000000000000000 0000000010026188 0000000010026160 00000000100288f0
[ 3051.629908] GPR24: 00007fffa2d13320 00000000000186a0 0000000010025dd8 0000000010055688
[ 3051.629908] GPR28: 0000000010024bb8 0000000000000001 0000000000000001 0000000000000000
[ 3051.630022] NIP [00007fffa2b92ffc] 0x7fffa2b92ffc
[ 3051.630032] LR [00007fffa2b92fcc] 0x7fffa2b92fcc
[ 3051.630041] --- interrupt: c00
[ 3051.630048] Instruction dump:
[ 3051.630057] 60000000 3c4c022c 38422260 7c0802a6 fbe1fff8 fba1ffe8 7c7f1b78 fbc1fff0
[ 3051.630078] f8010010 f821ffc1 e94d0030 e9230020 <7fca4aaa> 7fbe2214 7fa9fe76 7d2aea78
[ 3051.630102] ---[ end trace 83afe3a19212c333 ]---
[ 3051.633656]
[ 3052.633681] Kernel panic - not syncing: Fatal exception
5.13.0-next-20210630 was good. Bisect points to following patch:
commit 4ba3fcdde7e3
jbd2,ext4: add a shrinker to release checkpointed buffers
Reverting this patch allows the test to run successfully.
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix lockup on kernel exec fault
From: Christophe Leroy @ 2021-07-02 5:10 UTC (permalink / raw)
To: Nicholas Piggin, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1625188324.lt6lsizhsx.astroid@bobo.none>
Le 02/07/2021 à 03:25, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of July 1, 2021 9:17 pm:
>> The powerpc kernel is not prepared to handle exec faults from kernel.
>> Especially, the function is_exec_fault() will return 'false' when an
>> exec fault is taken by kernel, because the check is based on reading
>> current->thread.regs->trap which contains the trap from user.
>>
>> For instance, when provoking a LKDTM EXEC_USERSPACE test,
>> current->thread.regs->trap is set to SYSCALL trap (0xc00), and
>> the fault taken by the kernel is not seen as an exec fault by
>> set_access_flags_filter().
>>
>> Commit d7df2443cd5f ("powerpc/mm: Fix spurrious segfaults on radix
>> with autonuma") made it clear and handled it properly. But later on
>> commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute
>> faults") removed that handling, introducing test based on error_code.
>> And here is the problem, because on the 603 all upper bits of SRR1
>> get cleared when the TLB instruction miss handler bails out to ISI.
>
> So the problem is 603 doesn't see the DSISR_NOEXEC_OR_G bit?
I a way yes. But the problem is also that the kernel doesn't see it as an exec fault in
set_access_flags_filter() as explained above. If it could see it as an exec fault, it would set
PAGE_EXEC and it would work (or maybe not because it seems it also checks for the dirtiness of the
page, and here the page is also flagged as dirty).
603 will see DSISR_NOEXEC_OR_G if it's an access to a page which is in a segment flagged NX.
>
> I don't see the problem with this for 64s, I don't think anything sane
> can be done for any 0x400 interrupt in the kernel so it's probably
> good to catch all here just in case. For 64s,
>
> Acked-by: Nicholas Piggin <npiggin@gmail.com>
>
> Why is 32s clearing those top bits? And it seems to be setting DSISR
> that AFAIKS it does not use. Seems like it would be good to add a
> NOEXEC_OR_G bit into SRR1.
Probably for simplicity.
When taking the Instruction TLB Miss interrupt, SRR1 contains CR0 fields in bits 0-3 and some
dedicated info in bits 12-15. That doesn't match SRR1 bits for ISI, so before falling back to the
ISI handler, ITLB Miss handler error patch clears upper SRR1 bits.
Maybe it could instead try to set the right bits, but it would make it more complicated because the
error patch can be taken for the following reasons:
- No page table
- Not PAGE_PRESENT
- Not PAGE_ACCESSED
- Not PAGE_EXEC
- Below TASK_SIZE and not PAGE_USER
At the time being the verification of the flags is done with a single 'andc' operation. If we wanted
to set the proper bits, it would mean testing the flags separately, which would impact performance
on the no-error path.
Or maybe it would be good enough to set the PROTFAULT bit in all cases but the lack of page table.
The 8xx sets PROTFAULT when hitting non-exec pages, so the kernel is prepared for it anyway. Not
sure about the lack of PAGE_PRESENT thought. The 8xx sets NOHPTE bit when PAGE_PRESENT is cleared.
But is it really worth doing ?
Christophe
^ permalink raw reply
* [PATCH v2] Documentation: PCI: pci-error-recovery: swap sequence between MMIO Enabled and Link Reset
From: Wesley Sheng @ 2021-07-02 3:22 UTC (permalink / raw)
To: ruscur, oohall, linasvepstas, bhelgaas, corbet, linuxppc-dev,
linux-pci, linux-doc, linux-kernel
Cc: wesley.sheng, wesleyshenggit
Reset_link() callback function (named with reset_subordinates()
in pcie_do_recovery() function) was called before mmio_enabled(),
so exchange the sequence between step 2 MMIO Enabled and step 3
Link Reset accordingly.
Signed-off-by: Wesley Sheng <wesley.sheng@amd.com>
---
Documentation/PCI/pci-error-recovery.rst | 25 ++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst
index 187f43a03200..0e2f3f77bf0a 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -157,7 +157,7 @@ drivers.
If all drivers on the segment/slot return PCI_ERS_RESULT_CAN_RECOVER,
then the platform should re-enable IOs on the slot (or do nothing in
particular, if the platform doesn't isolate slots), and recovery
-proceeds to STEP 2 (MMIO Enable).
+proceeds to STEP 3 (MMIO Enable).
If any driver requested a slot reset (by returning PCI_ERS_RESULT_NEED_RESET),
then recovery proceeds to STEP 4 (Slot Reset).
@@ -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 to 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 the 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 v15 12/12] of: Add plumbing for restricted DMA pool
From: Guenter Roeck @ 2021-07-02 3:08 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, linux-devicetree, peterz, linux-pci, dri-devel,
chris, grant.likely, paulus, Frank Rowand, mingo, jxgao,
sstabellini, Saravana Kannan, Joerg Roedel, Rafael J . Wysocki,
Christoph Hellwig, Bartosz Golaszewski, bskeggs, xen-devel,
Marek Szyprowski, matthew.auld, Nicolas Boichat, thomas.hellstrom,
Will Deacon, Konrad Rzeszutek Wilk, intel-gfx, Dan Williams,
linuxppc-dev, Rob Herring, rodrigo.vivi, bhelgaas,
boris.ostrovsky, Andy Shevchenko, jgross, airlied, Thierry Reding,
Greg KH, Randy Dunlap, quic_qiancai, lkml, tfiga,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
thomas.lendacky, Robin Murphy, bauerman
In-Reply-To: <20210624155526.2775863-13-tientzu@chromium.org>
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
> If a device is not behind an IOMMU, we look up the device node and set
> up the restricted DMA when the restricted-dma-pool is presented.
>
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
> Tested-by: Will Deacon <will@kernel.org>
With this patch in place, all sparc and sparc64 qemu emulations
fail to boot. Symptom is that the root file system is not found.
Reverting this patch fixes the problem. Bisect log is attached.
Guenter
---
# bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux-next specific files for 20210701
# good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13
git bisect start 'HEAD' 'v5.13'
# bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch 'rdma/for-next'
git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90
# good: [46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4] Merge remote-tracking branch 'ipsec/master'
git bisect good 46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4
# good: [43ba6969cfb8185353a7a6fc79070f13b9e3d6d3] Merge remote-tracking branch 'clk/clk-next'
git bisect good 43ba6969cfb8185353a7a6fc79070f13b9e3d6d3
# good: [1ca5eddcf8dca1d6345471c6404e7364af0d7019] Merge remote-tracking branch 'fuse/for-next'
git bisect good 1ca5eddcf8dca1d6345471c6404e7364af0d7019
# good: [8f6d7b3248705920187263a4e7147b0752ec7dcf] Merge remote-tracking branch 'pci/next'
git bisect good 8f6d7b3248705920187263a4e7147b0752ec7dcf
# good: [df1885a755784da3ef285f36d9230c1d090ef186] RDMA/rtrs_clt: Alloc less memory with write path fast memory registration
git bisect good df1885a755784da3ef285f36d9230c1d090ef186
# good: [93d31efb58c8ad4a66bbedbc2d082df458c04e45] Merge remote-tracking branch 'cpufreq-arm/cpufreq/arm/linux-next'
git bisect good 93d31efb58c8ad4a66bbedbc2d082df458c04e45
# good: [46308965ae6fdc7c25deb2e8c048510ae51bbe66] RDMA/irdma: Check contents of user-space irdma_mem_reg_req object
git bisect good 46308965ae6fdc7c25deb2e8c048510ae51bbe66
# good: [6de7a1d006ea9db235492b288312838d6878385f] thermal/drivers/int340x/processor_thermal: Split enumeration and processing part
git bisect good 6de7a1d006ea9db235492b288312838d6878385f
# good: [081bec2577cda3d04f6559c60b6f4e2242853520] dt-bindings: of: Add restricted DMA pool
git bisect good 081bec2577cda3d04f6559c60b6f4e2242853520
# good: [bf95ac0bcd69979af146852f6a617a60285ebbc1] Merge remote-tracking branch 'thermal/thermal/linux-next'
git bisect good bf95ac0bcd69979af146852f6a617a60285ebbc1
# good: [3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc] RDMA/core: Always release restrack object
git bisect good 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc
# bad: [cff1f23fad6e0bd7d671acce0d15285c709f259c] Merge remote-tracking branch 'swiotlb/linux-next'
git bisect bad cff1f23fad6e0bd7d671acce0d15285c709f259c
# bad: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool
git bisect bad b655006619b7bccd0dc1e055bd72de5d613e7b5c
# first bad commit: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence
From: Wesley Sheng @ 2021-07-02 2:41 UTC (permalink / raw)
To: linasvepstas, ruscur, oohall, bhelgaas, corbet, linux-pci,
linuxppc-dev, linux-doc, linux-kernel
Cc: wesleyshenggit
In-Reply-To: <20210701222231.GA102933@bjorn-Precision-5520>
On Thu, Jul 01, 2021 at 05:22:31PM -0500, Bjorn Helgaas wrote:
> Please make the subject a little more specific. "rearrange the
> general sequence" doesn't say anything about what was affected.
>
> On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng 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.
>
> s/betwen/between/
>
> Not sure "general" adds anything in this sentence. "Step 2 and step
> 3" are not meaningful here in the commit log. It needs to spell out
> what those steps are so the log makes sense by itself.
>
> "reset_link" does not appear in pcie_do_recovery(). I'm guessing
> you're referring to the "reset_subordinates" function pointer?
>
Yes, you are right.
pcieaer-howto.rst has a section named with "Provide callbacks",
the callback supplied to pcie_do_recovery() was referred to
reset_link.
> > Signed-off-by: Wesley Sheng <wesley.sheng@amd.com>
>
> I didn't quite understand your response to Oliver, so I'll wait for
> your corrections and his ack before proceeding.
>
OK.
I thought step 2 MMIO Enabled and step 3 link reset should swap sequence.
> > ---
> > 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)
>
> s/or/to/ ?
>
> > .. 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.
>
> s/into next states/into the next state/ ?
>
> > 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
* [powerpc:merge] BUILD SUCCESS e289c2e239c638cab7e71143e0a65c7c4a057ad7
From: kernel test robot @ 2021-07-02 2:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: e289c2e239c638cab7e71143e0a65c7c4a057ad7 Automatic merge of 'next' into merge (2021-07-01 23:06)
elapsed time: 729m
configs tested: 116
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
powerpc sam440ep_defconfig
powerpc powernv_defconfig
powerpc acadia_defconfig
um defconfig
sh kfr2r09_defconfig
mips bmips_stb_defconfig
powerpc g5_defconfig
mips bmips_be_defconfig
arm ixp4xx_defconfig
arm oxnas_v6_defconfig
arm axm55xx_defconfig
powerpc sequoia_defconfig
xtensa common_defconfig
arm spear13xx_defconfig
mips bigsur_defconfig
ia64 generic_defconfig
arc nsimosci_hs_defconfig
xtensa nommu_kc705_defconfig
mips loongson2k_defconfig
sh sdk7780_defconfig
arm assabet_defconfig
m68k mvme147_defconfig
m68k m5272c3_defconfig
powerpc mpc837x_rdb_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20210630
i386 randconfig-a001-20210630
i386 randconfig-a003-20210630
i386 randconfig-a002-20210630
i386 randconfig-a005-20210630
i386 randconfig-a006-20210630
x86_64 randconfig-a002-20210630
x86_64 randconfig-a001-20210630
x86_64 randconfig-a004-20210630
x86_64 randconfig-a005-20210630
x86_64 randconfig-a006-20210630
x86_64 randconfig-a003-20210630
i386 randconfig-a014-20210630
i386 randconfig-a011-20210630
i386 randconfig-a016-20210630
i386 randconfig-a012-20210630
i386 randconfig-a013-20210630
i386 randconfig-a015-20210630
i386 randconfig-a015-20210701
i386 randconfig-a016-20210701
i386 randconfig-a011-20210701
i386 randconfig-a012-20210701
i386 randconfig-a013-20210701
i386 randconfig-a014-20210701
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210630
x86_64 randconfig-b001-20210702
x86_64 randconfig-a004-20210702
x86_64 randconfig-a005-20210702
x86_64 randconfig-a002-20210702
x86_64 randconfig-a006-20210702
x86_64 randconfig-a003-20210702
x86_64 randconfig-a001-20210702
x86_64 randconfig-a012-20210630
x86_64 randconfig-a015-20210630
x86_64 randconfig-a016-20210630
x86_64 randconfig-a013-20210630
x86_64 randconfig-a011-20210630
x86_64 randconfig-a014-20210630
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD REGRESSION 4ebbbaa4ce8524b853dd6febf0176a6efa3482d7
From: kernel test robot @ 2021-07-02 2:34 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 4ebbbaa4ce8524b853dd6febf0176a6efa3482d7 powerpc: Only build restart_table.c for 64s
possible Error/Warning in current branch:
arch/powerpc/platforms/4xx/pci.c:47:19: error: unused function 'ppc440spe_revA' [-Werror,-Wunused-function]
Error/Warning ids grouped by kconfigs:
clang_recent_errors
`-- powerpc64-randconfig-r016-20210630
`-- arch-powerpc-platforms-4xx-pci.c:error:unused-function-ppc440spe_revA-Werror-Wunused-function
elapsed time: 728m
configs tested: 139
configs skipped: 3
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm stm32_defconfig
powerpc wii_defconfig
powerpc currituck_defconfig
mips decstation_r4k_defconfig
arm omap2plus_defconfig
powerpc linkstation_defconfig
sh sh7763rdp_defconfig
sh espt_defconfig
arm u8500_defconfig
arm iop32x_defconfig
mips cu1830-neo_defconfig
powerpc socrates_defconfig
arm lart_defconfig
ia64 generic_defconfig
sh se7722_defconfig
sh ap325rxa_defconfig
sh se7724_defconfig
mips decstation_defconfig
sh edosk7760_defconfig
arm magician_defconfig
sh kfr2r09_defconfig
mips bmips_stb_defconfig
powerpc g5_defconfig
mips bmips_be_defconfig
arm ixp4xx_defconfig
arm oxnas_v6_defconfig
sh r7780mp_defconfig
arc nsim_700_defconfig
arm hisi_defconfig
h8300 h8300h-sim_defconfig
mips bigsur_defconfig
arc nsimosci_hs_defconfig
xtensa nommu_kc705_defconfig
sh rsk7203_defconfig
arm multi_v7_defconfig
mips loongson2k_defconfig
sh sdk7780_defconfig
arm assabet_defconfig
m68k mvme147_defconfig
m68k m5272c3_defconfig
powerpc mpc837x_rdb_defconfig
arm aspeed_g4_defconfig
sh rsk7269_defconfig
powerpc lite5200b_defconfig
mips qi_lb60_defconfig
xtensa defconfig
powerpc mpc512x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
x86_64 allnoconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a002-20210630
x86_64 randconfig-a001-20210630
x86_64 randconfig-a004-20210630
x86_64 randconfig-a005-20210630
x86_64 randconfig-a006-20210630
x86_64 randconfig-a003-20210630
i386 randconfig-a004-20210630
i386 randconfig-a001-20210630
i386 randconfig-a003-20210630
i386 randconfig-a002-20210630
i386 randconfig-a005-20210630
i386 randconfig-a006-20210630
i386 randconfig-a015-20210701
i386 randconfig-a016-20210701
i386 randconfig-a011-20210701
i386 randconfig-a012-20210701
i386 randconfig-a013-20210701
i386 randconfig-a014-20210701
i386 randconfig-a014-20210630
i386 randconfig-a011-20210630
i386 randconfig-a016-20210630
i386 randconfig-a012-20210630
i386 randconfig-a013-20210630
i386 randconfig-a015-20210630
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210630
x86_64 randconfig-b001-20210702
x86_64 randconfig-a004-20210702
x86_64 randconfig-a005-20210702
x86_64 randconfig-a002-20210702
x86_64 randconfig-a006-20210702
x86_64 randconfig-a003-20210702
x86_64 randconfig-a001-20210702
x86_64 randconfig-a012-20210630
x86_64 randconfig-a015-20210630
x86_64 randconfig-a016-20210630
x86_64 randconfig-a013-20210630
x86_64 randconfig-a011-20210630
x86_64 randconfig-a014-20210630
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix lockup on kernel exec fault
From: Nicholas Piggin @ 2021-07-02 1:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <024bb05105050f704743a0083fe3548702be5706.1625138205.git.christophe.leroy@csgroup.eu>
Excerpts from Christophe Leroy's message of July 1, 2021 9:17 pm:
> The powerpc kernel is not prepared to handle exec faults from kernel.
> Especially, the function is_exec_fault() will return 'false' when an
> exec fault is taken by kernel, because the check is based on reading
> current->thread.regs->trap which contains the trap from user.
>
> For instance, when provoking a LKDTM EXEC_USERSPACE test,
> current->thread.regs->trap is set to SYSCALL trap (0xc00), and
> the fault taken by the kernel is not seen as an exec fault by
> set_access_flags_filter().
>
> Commit d7df2443cd5f ("powerpc/mm: Fix spurrious segfaults on radix
> with autonuma") made it clear and handled it properly. But later on
> commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute
> faults") removed that handling, introducing test based on error_code.
> And here is the problem, because on the 603 all upper bits of SRR1
> get cleared when the TLB instruction miss handler bails out to ISI.
So the problem is 603 doesn't see the DSISR_NOEXEC_OR_G bit?
I don't see the problem with this for 64s, I don't think anything sane
can be done for any 0x400 interrupt in the kernel so it's probably
good to catch all here just in case. For 64s,
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Why is 32s clearing those top bits? And it seems to be setting DSISR
that AFAIKS it does not use. Seems like it would be good to add a
NOEXEC_OR_G bit into SRR1.
Thanks,
Nick
> Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy
> search_exception_tables() verification"), an exec fault from kernel
> at a userspace address was indirectly caught by the lack of entry for
> that address in the exception tables. But after that commit the
> kernel mainly rely on KUAP or on core mm handling to catch wrong
> user accesses. Here the access is not wrong, so mm handles it.
> It is a minor fault because PAGE_EXEC is not set,
> set_access_flags_filter() should set PAGE_EXEC and voila.
> But as is_exec_fault() returns false as explained in the begining,
> set_access_flags_filter() bails out without setting PAGE_EXEC flag,
> which leads to a forever minor exec fault.
>
> As the kernel is not prepared to handle such exec faults, the thing
> to do is to fire in bad_kernel_fault() for any exec fault taken by
> the kernel, as it was prior to commit d3ca587404b3.
>
> Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/fault.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 34f641d4a2fe..a8d0ce85d39a 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -199,9 +199,7 @@ static bool bad_kernel_fault(struct pt_regs *regs, unsigned long error_code,
> {
> int is_exec = TRAP(regs) == INTERRUPT_INST_STORAGE;
>
> - /* NX faults set DSISR_PROTFAULT on the 8xx, DSISR_NOEXEC_OR_G on others */
> - if (is_exec && (error_code & (DSISR_NOEXEC_OR_G | DSISR_KEYFAULT |
> - DSISR_PROTFAULT))) {
> + if (is_exec) {
> pr_crit_ratelimited("kernel tried to execute %s page (%lx) - exploit attempt? (uid: %d)\n",
> address >= TASK_SIZE ? "exec-protected" : "user",
> address,
> --
> 2.25.0
>
>
^ permalink raw reply
* Re: [PATCH v2] sched: Use BUG_ON
From: Jeremy Kerr @ 2021-07-02 1:19 UTC (permalink / raw)
To: Jason Wang; +Cc: arnd, linux-kernel, paulus, linuxppc-dev
In-Reply-To: <20210701141130.940-1-wangborong@cdjrlc.com>
Hi Jason,
> The BUG_ON macro simplifies the if condition followed by BUG, so that
> we can use BUG_ON instead of if condition followed by BUG.
[...]
> - if (spu_acquire(ctx))
> - BUG(); /* a kernel thread never has signals pending */
> + /* a kernel thread never has signals pending */
> + BUG_ON(spu_acquire(ctx));
I'm not convinced that this is an improvement; you've combined the
acquire and the BUG into a single statement, and now it's no longer
clear what the comment applies to.
If you really wanted to use BUG_ON, something like this would be more
clear:
rc = spu_acquire(ctx);
/* a kernel thread never has signals pending */
BUG_ON(rc);
but we don't have a suitable rc variable handy, so we'd need one of
those declared too. You could avoid that with:
if (spu_acquire(ctx))
BUG_ON(1); /* a kernel thread never has signals pending */
but wait: no need for the constant there, so this would be better:
if (spu_acquire(ctx))
BUG(); /* a kernel thread never has signals pending */
wait, what are we doing again?
To me, this is a bit of shuffling code around, for no real benefit.
Regards,
Jeremy
^ permalink raw reply
* Re: [RFC PATCH 10/43] powerpc/64s: Always set PMU control registers to frozen/disabled when not in use
From: Nicholas Piggin @ 2021-07-02 0:27 UTC (permalink / raw)
To: kvm-ppc, Madhavan Srinivasan; +Cc: linuxppc-dev
In-Reply-To: <c607e40c-5334-e8b1-11ac-c1464332e01a@linux.ibm.com>
Excerpts from Madhavan Srinivasan's message of July 1, 2021 11:17 pm:
>
> On 6/22/21 4:27 PM, Nicholas Piggin wrote:
>> KVM PMU management code looks for particular frozen/disabled bits in
>> the PMU registers so it knows whether it must clear them when coming
>> out of a guest or not. Setting this up helps KVM make these optimisations
>> without getting confused. Longer term the better approach might be to
>> move guest/host PMU switching to the perf subsystem.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/cpu_setup_power.c | 4 ++--
>> arch/powerpc/kernel/dt_cpu_ftrs.c | 6 +++---
>> arch/powerpc/kvm/book3s_hv.c | 5 +++++
>> arch/powerpc/perf/core-book3s.c | 7 +++++++
>> 4 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/cpu_setup_power.c b/arch/powerpc/kernel/cpu_setup_power.c
>> index a29dc8326622..3dc61e203f37 100644
>> --- a/arch/powerpc/kernel/cpu_setup_power.c
>> +++ b/arch/powerpc/kernel/cpu_setup_power.c
>> @@ -109,7 +109,7 @@ static void init_PMU_HV_ISA207(void)
>> static void init_PMU(void)
>> {
>> mtspr(SPRN_MMCRA, 0);
>> - mtspr(SPRN_MMCR0, 0);
>> + mtspr(SPRN_MMCR0, MMCR0_FC);
>
> Sticky point here is, currently if not frozen, pmc5/6 will
> keep countering. And not freezing them at boot is quiet useful
> sometime, like say when running in a simulation where we could calculate
> approx CPIs for micro benchmarks without perf subsystem.
You even can't use the sysfs files in this sim environment? In that case
what if we added a boot option that could set some things up? In that
case possibly you could even gather some more types of events too.
Thanks,
Nick
^ permalink raw reply
* [PATCH v3 4/5] powerpc: wii.dts: Expose the OTP on this platform
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210701225743.14631-1-linkmauve@linkmauve.fr>
This can be used by the newly-added nintendo-otp nvmem module.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
arch/powerpc/boot/dts/wii.dts | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index c5fb54f8cc02..e9c945b123c6 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -219,12 +219,17 @@ control@d800100 {
/*
* Both the address and length are wrong, according to
* Wiibrew this should be <0x0d800000 0x400>, but it
- * requires refactoring the PIC1 and GPIO nodes before
- * changing that.
+ * requires refactoring the PIC1, GPIO and OTP nodes
+ * before changing that.
*/
reg = <0x0d800100 0xa0>;
};
+ otp@d8001ec {
+ compatible = "nintendo,hollywood-otp";
+ reg = <0x0d8001ec 0x8>;
+ };
+
disk@d806000 {
compatible = "nintendo,hollywood-di";
reg = <0x0d806000 0x40>;
--
2.32.0
^ permalink raw reply related
* [PATCH v3 5/5] powerpc: wii_defconfig: Enable OTP by default
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210701225743.14631-1-linkmauve@linkmauve.fr>
This selects the nintendo-otp module when building for this platform.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
arch/powerpc/configs/wii_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/wii_defconfig b/arch/powerpc/configs/wii_defconfig
index 379c171f3ddd..a0c45bf2bfb1 100644
--- a/arch/powerpc/configs/wii_defconfig
+++ b/arch/powerpc/configs/wii_defconfig
@@ -99,6 +99,7 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_PANIC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_GENERIC=y
+CONFIG_NVMEM_NINTENDO_OTP=y
CONFIG_EXT2_FS=y
CONFIG_EXT4_FS=y
CONFIG_FUSE_FS=m
--
2.32.0
^ permalink raw reply related
* [PATCH v3 3/5] powerpc: wii.dts: Reduce the size of the control area
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210701225743.14631-1-linkmauve@linkmauve.fr>
This is wrong, but needed in order to avoid overlapping ranges with the
OTP area added in the next commit. A refactor of this part of the
device tree is needed: according to Wiibrew[1], this area starts at
0x0d800000 and spans 0x400 bytes (that is, 0x100 32-bit registers),
encompassing PIC and GPIO registers, amongst the ones already exposed in
this device tree, which should become children of the control@d800000
node.
[1] https://wiibrew.org/wiki/Hardware/Hollywood_Registers
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
arch/powerpc/boot/dts/wii.dts | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index aaa381da1906..c5fb54f8cc02 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -216,7 +216,13 @@ AVE: audio-video-encoder@70 {
control@d800100 {
compatible = "nintendo,hollywood-control";
- reg = <0x0d800100 0x300>;
+ /*
+ * Both the address and length are wrong, according to
+ * Wiibrew this should be <0x0d800000 0x400>, but it
+ * requires refactoring the PIC1 and GPIO nodes before
+ * changing that.
+ */
+ reg = <0x0d800100 0xa0>;
};
disk@d806000 {
--
2.32.0
^ permalink raw reply related
* [PATCH v3 2/5] dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210701225743.14631-1-linkmauve@linkmauve.fr>
Both of these consoles use the exact same two registers, even at the
same address, but the Wii U has eight banks of 128 bytes memory while
the Wii only has one, hence the two compatible strings.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
.../bindings/nvmem/nintendo-otp.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
new file mode 100644
index 000000000000..c39bd64b03b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/nintendo-otp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nintendo Wii and Wii U OTP Device Tree Bindings
+
+description: |
+ This binding represents the OTP memory as found on a Nintendo Wii or Wii U,
+ which contains common and per-console keys, signatures and related data
+ required to access peripherals.
+
+ See https://wiiubrew.org/wiki/Hardware/OTP
+
+maintainers:
+ - Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
+
+allOf:
+ - $ref: "nvmem.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - nintendo,hollywood-otp
+ - nintendo,latte-otp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ otp@d8001ec {
+ compatible = "nintendo,latte-otp";
+ reg = <0x0d8001ec 0x8>;
+ };
+
+...
--
2.32.0
^ permalink raw reply related
* [PATCH v3 1/5] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210701225743.14631-1-linkmauve@linkmauve.fr>
This OTP is read-only and contains various keys used by the console to
decrypt, encrypt or verify various pieces of storage.
Its size depends on the console, it is 128 bytes on the Wii and
1024 bytes on the Wii U (split into eight 128 bytes banks).
It can be used directly by writing into one register and reading from
the other one, without any additional synchronisation.
This driver was written based on reversed documentation, see:
https://wiiubrew.org/wiki/Hardware/OTP
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Tested-by: Jonathan Neuschäfer <j.ne@posteo.net> # on Wii
Tested-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> # on Wii U
---
drivers/nvmem/Kconfig | 11 ++++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 124 +++++++++++++++++++++++++++++++++++
3 files changed, 137 insertions(+)
create mode 100644 drivers/nvmem/nintendo-otp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index dd2019006838..39854d43758b 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -107,6 +107,17 @@ config MTK_EFUSE
This driver can also be built as a module. If so, the module
will be called efuse-mtk.
+config NVMEM_NINTENDO_OTP
+ tristate "Nintendo Wii and Wii U OTP Support"
+ help
+ This is a driver exposing the OTP of a Nintendo Wii or Wii U console.
+
+ This memory contains common and per-console keys, signatures and
+ related data required to access peripherals.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-nintendo-otp.
+
config QCOM_QFPROM
tristate "QCOM QFPROM Support"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index bbea1410240a..dcbbde35b6a8 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -23,6 +23,8 @@ obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
nvmem_lpc18xx_otp-y := lpc18xx_otp.o
obj-$(CONFIG_NVMEM_MXS_OCOTP) += nvmem-mxs-ocotp.o
nvmem-mxs-ocotp-y := mxs-ocotp.o
+obj-$(CONFIG_NVMEM_NINTENDO_OTP) += nvmem-nintendo-otp.o
+nvmem-nintendo-otp-y := nintendo-otp.o
obj-$(CONFIG_MTK_EFUSE) += nvmem_mtk-efuse.o
nvmem_mtk-efuse-y := mtk-efuse.o
obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
diff --git a/drivers/nvmem/nintendo-otp.c b/drivers/nvmem/nintendo-otp.c
new file mode 100644
index 000000000000..33961b17f9f1
--- /dev/null
+++ b/drivers/nvmem/nintendo-otp.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Nintendo Wii and Wii U OTP driver
+ *
+ * This is a driver exposing the OTP of a Nintendo Wii or Wii U console.
+ *
+ * This memory contains common and per-console keys, signatures and
+ * related data required to access peripherals.
+ *
+ * Based on reversed documentation from https://wiiubrew.org/wiki/Hardware/OTP
+ *
+ * Copyright (C) 2021 Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#define HW_OTPCMD 0
+#define HW_OTPDATA 4
+#define OTP_READ 0x80000000
+#define BANK_SIZE 128
+#define WORD_SIZE 4
+
+struct nintendo_otp_priv {
+ void __iomem *regs;
+};
+
+struct nintendo_otp_devtype_data {
+ const char *name;
+ unsigned int num_banks;
+};
+
+static const struct nintendo_otp_devtype_data hollywood_otp_data = {
+ .name = "wii-otp",
+ .num_banks = 1,
+};
+
+static const struct nintendo_otp_devtype_data latte_otp_data = {
+ .name = "wiiu-otp",
+ .num_banks = 8,
+};
+
+static int nintendo_otp_reg_read(void *context,
+ unsigned int reg, void *_val, size_t bytes)
+{
+ struct nintendo_otp_priv *priv = context;
+ u32 *val = _val;
+ int words = bytes / WORD_SIZE;
+ u32 bank, addr;
+
+ while (words--) {
+ bank = (reg / BANK_SIZE) << 8;
+ addr = (reg / WORD_SIZE) % (BANK_SIZE / WORD_SIZE);
+ iowrite32be(OTP_READ | bank | addr, priv->regs + HW_OTPCMD);
+ *val++ = ioread32be(priv->regs + HW_OTPDATA);
+ reg += WORD_SIZE;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id nintendo_otp_of_table[] = {
+ { .compatible = "nintendo,hollywood-otp", .data = &hollywood_otp_data },
+ { .compatible = "nintendo,latte-otp", .data = &latte_otp_data },
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, nintendo_otp_of_table);
+
+static int nintendo_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *of_id =
+ of_match_device(nintendo_otp_of_table, dev);
+ struct resource *res;
+ struct nvmem_device *nvmem;
+ struct nintendo_otp_priv *priv;
+
+ struct nvmem_config config = {
+ .stride = WORD_SIZE,
+ .word_size = WORD_SIZE,
+ .reg_read = nintendo_otp_reg_read,
+ .read_only = true,
+ .root_only = true,
+ };
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ if (of_id->data) {
+ const struct nintendo_otp_devtype_data *data = of_id->data;
+ config.name = data->name;
+ config.size = data->num_banks * BANK_SIZE;
+ }
+
+ config.dev = dev;
+ config.priv = priv;
+
+ nvmem = devm_nvmem_register(dev, &config);
+
+ return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static struct platform_driver nintendo_otp_driver = {
+ .probe = nintendo_otp_probe,
+ .driver = {
+ .name = "nintendo-otp",
+ .of_match_table = nintendo_otp_of_table,
+ },
+};
+module_platform_driver(nintendo_otp_driver);
+MODULE_AUTHOR("Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>");
+MODULE_DESCRIPTION("Nintendo Wii and Wii U OTP driver");
+MODULE_LICENSE("GPL v2");
--
2.32.0
^ permalink raw reply related
* [PATCH v3 0/5] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-07-01 22:57 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
In-Reply-To: <20210519095044.4109-1-linkmauve@linkmauve.fr>
The OTP is a read-only memory area which contains various keys and
signatures used to decrypt, encrypt or verify various pieces of storage.
Its size depends on the console, it is 128 bytes on the Wii and
1024 bytes on the Wii U (split into eight 128 bytes banks).
It can be used directly by writing into one register and reading from
the other one, without any additional synchronisation.
This series has been tested on both the Wii U (using my downstream
master-wiiu branch[1]), as well as on the Wii on mainline.
[1] https://gitlab.com/linkmauve/linux-wiiu/-/commits/master-wiiu
Changes since v1:
- Fixed the commit messages so they can be accepted by other email
servers, sorry about that.
Changes since v2:
- Switched the dt binding documentation to YAML.
- Used more obvious register arithmetic, and tested that gcc (at -O1 and
above) outputs the exact same rlwinm instructions for them.
- Use more #defines to make the code easier to read.
- Include some links to the reversed documentation.
- Avoid overlapping dt regions by changing the existing control@d800100
node to end before the OTP registers, with some bigger dt refactoring
left for a future series.
Emmanuel Gil Peyrot (5):
nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
powerpc: wii.dts: Reduce the size of the control area
powerpc: wii.dts: Expose the OTP on this platform
powerpc: wii_defconfig: Enable OTP by default
.../bindings/nvmem/nintendo-otp.yaml | 44 +++++++
arch/powerpc/boot/dts/wii.dts | 13 +-
arch/powerpc/configs/wii_defconfig | 1 +
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 124 ++++++++++++++++++
6 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml
create mode 100644 drivers/nvmem/nintendo-otp.c
--
2.32.0
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence
From: Bjorn Helgaas @ 2021-07-01 22:22 UTC (permalink / raw)
To: Wesley Sheng
Cc: wesleyshenggit, corbet, linux-pci, linux-doc, linux-kernel,
oohall, bhelgaas, linasvepstas, linuxppc-dev
In-Reply-To: <20210618060446.7969-1-wesley.sheng@amd.com>
Please make the subject a little more specific. "rearrange the
general sequence" doesn't say anything about what was affected.
On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng 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.
s/betwen/between/
Not sure "general" adds anything in this sentence. "Step 2 and step
3" are not meaningful here in the commit log. It needs to spell out
what those steps are so the log makes sense by itself.
"reset_link" does not appear in pcie_do_recovery(). I'm guessing
you're referring to the "reset_subordinates" function pointer?
> Signed-off-by: Wesley Sheng <wesley.sheng@amd.com>
I didn't quite understand your response to Oliver, so I'll wait for
your corrections and his ack before proceeding.
> ---
> 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)
s/or/to/ ?
> .. 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.
s/into next states/into the next state/ ?
> 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
* Re: [PATCH v2 3/4] powerpc: wii.dts: Expose the OTP on this platform
From: Emmanuel Gil Peyrot @ 2021-07-01 19:56 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: devicetree, Emmanuel Gil Peyrot, linux-kernel, Rob Herring,
Srinivas Kandagatla, Ash Logan, Paul Mackerras, linuxppc-dev
In-Reply-To: <YNe5aW55SrXFGKFV@latitude>
[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]
On Sat, Jun 26, 2021 at 11:34:01PM +0000, Jonathan Neuschäfer wrote:
> On Wed, May 19, 2021 at 11:50:43AM +0200, Emmanuel Gil Peyrot wrote:
> > This can be used by the newly-added nintendo-otp nvmem module.
> >
> > Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
> > ---
> > arch/powerpc/boot/dts/wii.dts | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
> > index aaa381da1906..7837c4a3f09c 100644
> > --- a/arch/powerpc/boot/dts/wii.dts
> > +++ b/arch/powerpc/boot/dts/wii.dts
> > @@ -219,6 +219,11 @@ control@d800100 {
> > reg = <0x0d800100 0x300>;
> > };
> >
> > + otp@d8001ec {
> > + compatible = "nintendo,hollywood-otp";
> > + reg = <0x0d8001ec 0x8>;
>
> The OTP registers overlap with the previous node, control@d800100.
> Not sure what's the best way to structure the devicetree in this case,
> maybe something roughly like the following (untested, unverified):
[snip]
I couldn’t get this to work, but additionally it looks like it should
start 0x100 earlier and contain pic1@d800030 and gpio@d8000c0, given
https://wiibrew.org/wiki/Hardware/Hollywood_Registers
Would it make sense, for the time being, to reduce the size of this
control@d800100 device to the single register currently being used by
arch/powerpc/platforms/embedded6xx/wii.c (0xd800194, used to reboot the
system) and leave the refactor of restart + OTP + PIC + GPIO for a
future series?
Thanks,
--
Emmanuel Gil Peyrot
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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