* [PATCH 4/5] powerpc/kprobes: Refactor arch_prepare_kprobe()
From: Naveen N. Rao @ 2021-05-19 10:47 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Jordan Niethe; +Cc: linuxppc-dev
In-Reply-To: <cover.1621416666.git.naveen.n.rao@linux.vnet.ibm.com>
Clean up the function to look sane:
- return immediately on error, rather than pointlessly setting the
return value
- pr_info() instead of printk()
- check return value of patch_instruction()
- and to top it all of: a reverse christmas tree!
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/kprobes.c | 64 +++++++++++++++++------------------
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index bbef9e918ecb39..7195162362941f 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -105,56 +105,54 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, unsigned int offset)
int arch_prepare_kprobe(struct kprobe *p)
{
- int ret = 0;
+ struct ppc_inst insn = ppc_inst_read((struct ppc_inst *)p->addr);
+ struct instruction_op op;
struct kprobe *prev;
struct pt_regs regs;
- struct instruction_op op;
- struct ppc_inst insn = ppc_inst_read((struct ppc_inst *)p->addr);
+ int ret = 0;
if ((unsigned long)p->addr & 0x03) {
- printk("Attempt to register kprobe at an unaligned address\n");
- ret = -EINVAL;
+ pr_info("Attempt to register kprobe at an unaligned address\n");
+ return -EINVAL;
} else if (IS_MTMSRD(insn) || IS_RFID(insn)) {
- printk("Cannot register a kprobe on mtmsr[d]/rfi[d]\n");
- ret = -EINVAL;
+ pr_info("Cannot register a kprobe on mtmsr[d]/rfi[d]\n");
+ return -EINVAL;
} else if ((unsigned long)p->addr & ~PAGE_MASK &&
ppc_inst_prefixed(ppc_inst_read((struct ppc_inst *)(p->addr - 1)))) {
- printk("Cannot register a kprobe on the second word of prefixed instruction\n");
- ret = -EINVAL;
+ pr_info("Cannot register a kprobe on the second word of prefixed instruction\n");
+ return -EINVAL;
}
+
+ /* Check if the previous instruction is a prefix instruction with an active kprobe */
preempt_disable();
prev = get_kprobe(p->addr - 1);
preempt_enable_no_resched();
- if (prev &&
- ppc_inst_prefixed(ppc_inst_read((struct ppc_inst *)prev->ainsn.insn))) {
- printk("Cannot register a kprobe on the second word of prefixed instruction\n");
- ret = -EINVAL;
+ if (prev && ppc_inst_prefixed(ppc_inst_read((struct ppc_inst *)prev->ainsn.insn))) {
+ pr_info("Cannot register a kprobe on the second word of prefixed instruction\n");
+ return -EINVAL;
}
/* insn must be on a special executable page on ppc64. This is
* not explicitly required on ppc32 (right now), but it doesn't hurt */
- if (!ret) {
- p->ainsn.insn = get_insn_slot();
- if (!p->ainsn.insn)
- ret = -ENOMEM;
- }
+ p->ainsn.insn = get_insn_slot();
+ if (!p->ainsn.insn)
+ return -ENOMEM;
- if (!ret) {
- patch_instruction((struct ppc_inst *)p->ainsn.insn, insn);
- p->opcode = ppc_inst_val(insn);
-
- /* Check if this is an instruction we recognise */
- p->ainsn.boostable = 0;
- memset(®s, 0, sizeof(struct pt_regs));
- regs.nip = (unsigned long)p->addr;
- regs.msr = MSR_KERNEL;
- ret = analyse_instr(&op, ®s, insn);
- if (ret == 1 || (ret == 0 && GETTYPE(op.type) != UNKNOWN))
- p->ainsn.boostable = 1;
- ret = 0;
- }
+ if (patch_instruction((struct ppc_inst *)p->ainsn.insn, insn))
+ return -EFAULT;
- return ret;
+ p->opcode = ppc_inst_val(insn);
+
+ /* Check if this is an instruction we recognise */
+ p->ainsn.boostable = 0;
+ memset(®s, 0, sizeof(struct pt_regs));
+ regs.nip = (unsigned long)p->addr;
+ regs.msr = MSR_KERNEL;
+ ret = analyse_instr(&op, ®s, insn);
+ if (ret == 1 || (ret == 0 && GETTYPE(op.type) != UNKNOWN))
+ p->ainsn.boostable = 1;
+
+ return 0;
}
NOKPROBE_SYMBOL(arch_prepare_kprobe);
--
2.30.2
^ permalink raw reply related
* [PATCH 5/5] powerpc/kprobes: Warn if instruction patching failed
From: Naveen N. Rao @ 2021-05-19 10:47 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, Jordan Niethe; +Cc: linuxppc-dev
In-Reply-To: <cover.1621416666.git.naveen.n.rao@linux.vnet.ibm.com>
When arming and disarming probes, we currently assume that instruction
patching can never fail, and don't have a mechanism to surface errors.
Add a warning in case instruction patching ever fails.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/kprobes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 7195162362941f..e0190e75a221eb 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -158,13 +158,13 @@ NOKPROBE_SYMBOL(arch_prepare_kprobe);
void arch_arm_kprobe(struct kprobe *p)
{
- patch_instruction((struct ppc_inst *)p->addr, ppc_inst(BREAKPOINT_INSTRUCTION));
+ WARN_ON_ONCE(patch_instruction((struct ppc_inst *)p->addr, ppc_inst(BREAKPOINT_INSTRUCTION)));
}
NOKPROBE_SYMBOL(arch_arm_kprobe);
void arch_disarm_kprobe(struct kprobe *p)
{
- patch_instruction((struct ppc_inst *)p->addr, ppc_inst(p->opcode));
+ WARN_ON_ONCE(patch_instruction((struct ppc_inst *)p->addr, ppc_inst(p->opcode)));
}
NOKPROBE_SYMBOL(arch_disarm_kprobe);
--
2.30.2
^ permalink raw reply related
* Re: Linux powerpc new system call instruction and ABI
From: Nicholas Piggin @ 2021-05-19 10:59 UTC (permalink / raw)
To: Dmitry V. Levin
Cc: libc-alpha, Matheus Castanho, musl, linux-api, libc-dev,
linuxppc-dev
In-Reply-To: <20210519102403.GA15207@altlinux.org>
Excerpts from Dmitry V. Levin's message of May 19, 2021 8:24 pm:
> On Wed, May 19, 2021 at 12:50:24PM +1000, Nicholas Piggin wrote:
> [...]
>> With this patch, I think the ptrace ABI should mostly be fixed. I think
>> a problem remains with applications that look at system call return
>> registers directly and have powerpc specific error cases. Those probably
>> will just need to be updated unfortunately. Michael thought it might be
>> possible to return an indication via ptrace somehow that the syscall is
>> using a new ABI, so such apps can be updated to test for it. I don't
>> know how that would be done.
>
> Is there any sane way for these applications to handle the scv case?
> How can they tell that the scv semantics is being used for the given
> syscall invocation? Can this information be obtained e.g. from struct
> pt_regs?
Not that I know of. Michael suggested there might be a way to add
something. ptrace_syscall_info has some pad bytes, could
we use one for flags bits and set a bit for "new system call ABI"?
As a more hacky thing you could make a syscall with -1 and see how
the error looks, and then assume all syscalls will be the same.
Thanks,
Nick
>
> For example, in strace we have the following powerpc-specific code used
> for syscall tampering:
>
> $ cat src/linux/powerpc/set_error.c
> /*
> * Copyright (c) 2016-2021 The strace developers.
> * All rights reserved.
> *
> * SPDX-License-Identifier: LGPL-2.1-or-later
> */
>
> static int
> arch_set_r3_ccr(struct tcb *tcp, const unsigned long r3,
> const unsigned long ccr_set, const unsigned long ccr_clear)
> {
> if (ptrace_syscall_info_is_valid() &&
> upeek(tcp, sizeof(long) * PT_CCR, &ppc_regs.ccr))
> return -1;
> const unsigned long old_ccr = ppc_regs.ccr;
> ppc_regs.gpr[3] = r3;
> ppc_regs.ccr |= ccr_set;
> ppc_regs.ccr &= ~ccr_clear;
> if (ppc_regs.ccr != old_ccr &&
> upoke(tcp, sizeof(long) * PT_CCR, ppc_regs.ccr))
> return -1;
> return upoke(tcp, sizeof(long) * (PT_R0 + 3), ppc_regs.gpr[3]);
> }
>
> static int
> arch_set_error(struct tcb *tcp)
> {
> return arch_set_r3_ccr(tcp, tcp->u_error, 0x10000000, 0);
> }
>
> static int
> arch_set_success(struct tcb *tcp)
> {
> return arch_set_r3_ccr(tcp, tcp->u_rval, 0, 0x10000000);
> }
>
>
> --
> ldv
>
^ permalink raw reply
* Re: [PATCH v3 5/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Nicholas Piggin @ 2021-05-19 11:09 UTC (permalink / raw)
To: Peter Zijlstra, Ricardo Neri
Cc: Juri Lelli, Len Brown, Ricardo Neri, Vincent Guittot, Tim Chen,
Ravi V. Shankar, Quentin Perret, linuxppc-dev, Aubrey Li,
linux-kernel, Steven Rostedt, Ingo Molnar, Ben Segall, Aubrey Li,
Srinivas Pandruvada, Joel Fernandes (Google),
Daniel Bristot de Oliveira, Dietmar Eggemann, Mel Gorman
In-Reply-To: <YKThlA2yZBT2KuvW@hirez.programming.kicks-ass.net>
Excerpts from Peter Zijlstra's message of May 19, 2021 7:59 pm:
> On Tue, May 18, 2021 at 12:07:40PM -0700, Ricardo Neri wrote:
>> On Fri, May 14, 2021 at 07:14:15PM -0700, Ricardo Neri wrote:
>> > On Fri, May 14, 2021 at 11:47:45AM +0200, Peter Zijlstra wrote:
>
>> > > So I'm thinking that this is a property of having ASYM_PACKING at a core
>> > > level, rather than some arch special. Wouldn't something like this be
>> > > more appropriate?
>
>> > Thanks Peter for the quick review! This makes sense to me. The only
>> > reason we proposed arch_asym_check_smt_siblings() is because we were
>> > about breaking powerpc (I need to study how they set priorities for SMT,
>> > if applicable). If you think this is not an issue I can post a
>> > v4 with this update.
>>
>> As far as I can see, priorities in powerpc are set by the CPU number.
>> However, I am not sure how CPUs are enumerated? If CPUs in brackets are
>> SMT sibling, Does an enumeration looks like A) [0, 1], [2, 3] or B) [0, 2],
>> [1, 3]? I guess B is the right answer. Otherwise, both SMT siblings of a
>> core would need to be busy before a new core is used.
>>
>> Still, I think the issue described in the cover letter may be
>> reproducible in powerpc as well. If CPU3 is offlined, and [0, 2] pulled
>> tasks from [1, -] so that both CPU0 and CPU2 become busy, CPU1 would not be
>> able to help since CPU0 has the highest priority.
>>
>> I am cc'ing the linuxppc list to get some feedback.
>
> IIRC the concern with Power is that their Cores can go faster if the
> higher SMT siblings are unused.
>
> That is, suppose you have an SMT4 Core with only a single active task,
> then if only SMT0 is used it can reach max performance, but if the
> active sibling is SMT1 it can not reach max performance, and if the only
> active sibling is SMT2 it goes slower still.
>
> So they need to pack the tasks to the lowest SMT siblings, and have the
> highest SMT siblings idle (where possible) in order to increase
> performance.
That's correct.
Thanks,
Nick
^ permalink raw reply
* Re: Linux powerpc new system call instruction and ABI
From: Nicholas Piggin @ 2021-05-19 11:12 UTC (permalink / raw)
To: Joakim Tjernlund, ldv@altlinux.org, mpe@ellerman.id.au
Cc: libc-dev@lists.llvm.org, musl@lists.openwall.com,
linuxppc-dev@lists.ozlabs.org, linux-api@vger.kernel.org
In-Reply-To: <1621413143.oec64jaci5.astroid@bobo.none>
Excerpts from Nicholas Piggin's message of May 19, 2021 6:42 pm:
> Excerpts from Joakim Tjernlund's message of May 19, 2021 6:08 pm:
>> On Wed, 2021-05-19 at 17:55 +1000, Nicholas Piggin wrote:
>>> Excerpts from Joakim Tjernlund's message of May 19, 2021 5:33 pm:
>>> > On Wed, 2021-05-19 at 02:13 +0300, Dmitry V. Levin wrote:
>>> > > Hi,
>>> > >
>>> > > On Thu, Jun 11, 2020 at 06:12:01PM +1000, Nicholas Piggin wrote:
>>> > > [...]
>>> > > > - Error handling: The consensus among kernel, glibc, and musl is to move to
>>> > > > using negative return values in r3 rather than CR0[SO]=1 to indicate error,
>>> > > > which matches most other architectures, and is closer to a function call.
>>> >
>>> > What about syscalls like times(2) which can return -1 without it being an error?
>>>
>>> They do become errors / indistinguishable and have to be dealt with by
>>> libc or userspace. Which does follow what most architectures do (all
>>> except ia64, mips, sparc, and powerpc actually).
>>>
>>> Interesting question though, it should have been noted.
>>>
>>> Thanks,
>>> Nick
>>
>> I always figured the ppc way was superior. It begs the question if not the other archs should
>> change instead?
>
> It is superior in some ways, not enough to be worth being different.
>
> Other archs are unlikely to change because it would be painful for
> not much benefit. New system calls just should be made to not return
> error numbers. If we ever had a big new version of syscall ABI in
> Linux, we can always use another scv vector number for it.
Or... is it possible at syscall entry to peek the address of
the instruction which caused the call and see if that was a
scv instruction? That would be about as reliable as possible
without having that new flag bit.
Thanks,
Nick
^ permalink raw reply
* Re: [FSL P50x0] KVM HV doesn't work anymore
From: Christian Zigotzky @ 2021-05-19 11:52 UTC (permalink / raw)
To: Nicholas Piggin, Christophe Leroy, kvm-ppc@vger.kernel.org,
linuxppc-dev
Cc: Darren Stevens, R.T.Dickinson, mad skateman, Christian Zigotzky
In-Reply-To: <1621410977.cgh0d6nvlo.astroid@bobo.none>
On 19 May 2021 at 09:57 am, Nicholas Piggin wrote:
> Excerpts from Christian Zigotzky's message of May 17, 2021 7:42 pm:
>> On 17 May 2021 at 09:42am, Nicholas Piggin wrote:
>>> Excerpts from Christian Zigotzky's message of May 15, 2021 11:46 pm:
>>>> I tried it but it doesn't solve the issue. The uImage works without
>>>> KVM
>>>> HV in a virtual e5500 QEMU machine.
>>> Any more progress with this? I would say that bisect might have just
>>> been a bit unstable and maybe by chance some things did not crash so
>>> it's pointing to the wrong patch.
>>>
>>> Upstream merge of powerpc-5.13-1 was good and powerpc-5.13-2 was bad?
>>>
>>> Between that looks like some KVM MMU rework. You could try the patch
>>> before this one b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU
>>> notifier callbacks"). That won't revert cleanly so just try run the
>>> tree at that point. If it works, test the patch and see if it fails.
>>>
>>> Thanks,
>>> Nick
>> Hi Nick,
>>
>> Thanks a lot for your answer. Yes, there is a little bit of progress.
>> The RC2 of kernel 5.13 successfully boots with -smp 3 in a virtual e5500
>> QEMU machine.
>> -smp 4 doesn't work anymore since the PowerPC updates 5.13-2. I used
>> -smp 4 before 5.13 because my FSL P5040 machine has 4 cores.
>>
>> Could you please post a patch for reverting the commit before
>> b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")?
> You could `git checkout b1c5356e873c~1`
>
> Thanks,
> Nick
Hi Nick,
Thanks for your answer. I checked out the commit b1c5356e873c~1 (HEAD is
now at d923ff258423 KVM: MIPS/MMU: Convert to the gfn-based MMU notifier
callbacks).
The kernel boots with '-smp 4' without any problems.
After that I patched with the probable first bad commit (KVM: PPC:
Convert to the gfn-based MMU notifier callbacks). The kernel also boots
with this patch. That means, this isn't the first bad commit.
Further information:
https://forum.hyperion-entertainment.com/viewtopic.php?p=53267#p53267
Cheers,
Christian
^ permalink raw reply
* [PATCH 3/4] powerpc: wii.dts: Expose the OTP on this platform
From: Emmanuel Gil Peyrot @ 2021-05-19 9:05 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: <20210519090525.1788-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 | 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>;
+ };
+
disk@d806000 {
compatible = "nintendo,hollywood-di";
reg = <0x0d806000 0x40>;
--
2.31.1
^ permalink raw reply related
* [PATCH 0/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:05 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
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 only been tested on the Wii U so far, using the
downstream 4.19 branch from linux-wiiu[1], but it should also work on
the Wii on mainline.
[1] https://gitlab.com/linux-wiiu/linux-wiiu
Emmanuel Gil Peyrot (4):
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: Expose the OTP on this platform
powerpc: wii_defconfig: Enable OTP by default
.../bindings/nvmem/nintendo-otp.txt | 14 +++
arch/powerpc/boot/dts/wii.dts | 5 +
arch/powerpc/configs/wii_defconfig | 1 +
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 ++++++++++++++++++
6 files changed, 148 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
create mode 100644 drivers/nvmem/nintendo-otp.c
--
2.31.1
^ permalink raw reply
* [PATCH 4/4] powerpc: wii_defconfig: Enable OTP by default
From: Emmanuel Gil Peyrot @ 2021-05-19 9:05 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: <20210519090525.1788-1-linkmauve@linkmauve.fr>
This selects the nintendo-otp module when building for this platform, if
CONFIG_NVMEM is also selected.
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.31.1
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
From: Emmanuel Gil Peyrot @ 2021-05-19 9:05 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: <20210519090525.1788-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>
---
.../devicetree/bindings/nvmem/nintendo-otp.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
new file mode 100644
index 000000000000..b26d705ec52d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
@@ -0,0 +1,14 @@
+Nintendo Wii and Wii U OTP
+
+Required Properties:
+- compatible: depending on the console this should be one of:
+ - "nintendo,hollywood-otp" for the Wii
+ - "nintendo,latte-otp" for the Wii U
+- reg: base address and size of the OTP registers
+
+
+Example:
+ otp@d8001ec {
+ compatible = "nintendo,latte-otp";
+ reg = <0x0d8001ec 0x8>;
+ };
--
2.31.1
^ permalink raw reply related
* [PATCH 1/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:05 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: <20210519090525.1788-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.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
drivers/nvmem/Kconfig | 11 ++++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 +++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/nvmem/nintendo-otp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index dd2019006838..dd6196e49b2d 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 to expose the OTP on a Nintendo Wii or Wii U.
+
+ 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..de6f5d7c10ef
--- /dev/null
+++ b/drivers/nvmem/nintendo-otp.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Nintendo Wii and Wii U OTP driver
+ *
+ * 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
+
+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 >> 2;
+ u32 bank, addr;
+
+ while (words--) {
+ bank = (reg << 1) & ~0xff;
+ addr = (reg >> 2) & 0x1f;
+ iowrite32be(OTP_READ | bank | addr, priv->regs + HW_OTPCMD);
+ *val++ = ioread32be(priv->regs + HW_OTPDATA);
+ reg += 4;
+ }
+
+ 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 = 4,
+ .word_size = 4,
+ .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 * 128;
+ }
+
+ 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.31.1
^ permalink raw reply related
* [PATCH 0/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:45 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
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 only been tested on the Wii U so far, using the
downstream 4.19 branch from linux-wiiu[1], but it should also work on
the Wii on mainline.
[1] https://gitlab.com/linux-wiiu/linux-wiiu
Emmanuel Gil Peyrot (4):
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: Expose the OTP on this platform
powerpc: wii_defconfig: Enable OTP by default
.../bindings/nvmem/nintendo-otp.txt | 14 +++
arch/powerpc/boot/dts/wii.dts | 5 +
arch/powerpc/configs/wii_defconfig | 1 +
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 ++++++++++++++++++
6 files changed, 148 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
create mode 100644 drivers/nvmem/nintendo-otp.c
--
2.31.1
^ permalink raw reply
* [PATCH 1/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:45 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: <20210519094546.3954-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.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
drivers/nvmem/Kconfig | 11 ++++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 +++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/nvmem/nintendo-otp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index dd2019006838..dd6196e49b2d 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 to expose the OTP on a Nintendo Wii or Wii U.
+
+ 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..de6f5d7c10ef
--- /dev/null
+++ b/drivers/nvmem/nintendo-otp.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Nintendo Wii and Wii U OTP driver
+ *
+ * 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
+
+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 >> 2;
+ u32 bank, addr;
+
+ while (words--) {
+ bank = (reg << 1) & ~0xff;
+ addr = (reg >> 2) & 0x1f;
+ iowrite32be(OTP_READ | bank | addr, priv->regs + HW_OTPCMD);
+ *val++ = ioread32be(priv->regs + HW_OTPDATA);
+ reg += 4;
+ }
+
+ 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 = 4,
+ .word_size = 4,
+ .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 * 128;
+ }
+
+ 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.31.1
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
From: Emmanuel Gil Peyrot @ 2021-05-19 9:45 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: <20210519094546.3954-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>
---
.../devicetree/bindings/nvmem/nintendo-otp.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
new file mode 100644
index 000000000000..b26d705ec52d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
@@ -0,0 +1,14 @@
+Nintendo Wii and Wii U OTP
+
+Required Properties:
+- compatible: depending on the console this should be one of:
+ - "nintendo,hollywood-otp" for the Wii
+ - "nintendo,latte-otp" for the Wii U
+- reg: base address and size of the OTP registers
+
+
+Example:
+ otp@d8001ec {
+ compatible = "nintendo,latte-otp";
+ reg = <0x0d8001ec 0x8>;
+ };
--
2.31.1
^ permalink raw reply related
* [PATCH 3/4] powerpc: wii.dts: Expose the OTP on this platform
From: Emmanuel Gil Peyrot @ 2021-05-19 9:45 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: <20210519094546.3954-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 | 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>;
+ };
+
disk@d806000 {
compatible = "nintendo,hollywood-di";
reg = <0x0d806000 0x40>;
--
2.31.1
^ permalink raw reply related
* [PATCH 4/4] powerpc: wii_defconfig: Enable OTP by default
From: Emmanuel Gil Peyrot @ 2021-05-19 9:45 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: <20210519094546.3954-1-linkmauve@linkmauve.fr>
This selects the nintendo-otp module when building for this platform, if
CONFIG_NVMEM is also selected.
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.31.1
^ permalink raw reply related
* [PATCH v2 0/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:50 UTC (permalink / raw)
To: Srinivas Kandagatla, linuxppc-dev, devicetree
Cc: Emmanuel Gil Peyrot, linux-kernel, Rob Herring, Paul Mackerras,
Ash Logan, Jonathan Neuschäfer
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 only been tested on the Wii U so far, using the
downstream 4.19 branch from linux-wiiu[1], but it should also work on
the Wii on mainline.
[1] https://gitlab.com/linux-wiiu/linux-wiiu
Changes since v1:
- Fixed the commit messages so they can be accepted by other email
servers, sorry about that.
Emmanuel Gil Peyrot (4):
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: Expose the OTP on this platform
powerpc: wii_defconfig: Enable OTP by default
.../bindings/nvmem/nintendo-otp.txt | 14 +++
arch/powerpc/boot/dts/wii.dts | 5 +
arch/powerpc/configs/wii_defconfig | 1 +
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 ++++++++++++++++++
6 files changed, 148 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
create mode 100644 drivers/nvmem/nintendo-otp.c
--
2.31.1
^ permalink raw reply
* [PATCH v2 1/4] nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP
From: Emmanuel Gil Peyrot @ 2021-05-19 9:50 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>
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.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
---
drivers/nvmem/Kconfig | 11 ++++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/nintendo-otp.c | 115 +++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/nvmem/nintendo-otp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index dd2019006838..dd6196e49b2d 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 to expose the OTP on a Nintendo Wii or Wii U.
+
+ 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..de6f5d7c10ef
--- /dev/null
+++ b/drivers/nvmem/nintendo-otp.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Nintendo Wii and Wii U OTP driver
+ *
+ * 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
+
+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 >> 2;
+ u32 bank, addr;
+
+ while (words--) {
+ bank = (reg << 1) & ~0xff;
+ addr = (reg >> 2) & 0x1f;
+ iowrite32be(OTP_READ | bank | addr, priv->regs + HW_OTPCMD);
+ *val++ = ioread32be(priv->regs + HW_OTPDATA);
+ reg += 4;
+ }
+
+ 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 = 4,
+ .word_size = 4,
+ .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 * 128;
+ }
+
+ 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.31.1
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: nintendo-otp: Document the Wii and Wii U OTP support
From: Emmanuel Gil Peyrot @ 2021-05-19 9:50 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>
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>
---
.../devicetree/bindings/nvmem/nintendo-otp.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
new file mode 100644
index 000000000000..b26d705ec52d
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.txt
@@ -0,0 +1,14 @@
+Nintendo Wii and Wii U OTP
+
+Required Properties:
+- compatible: depending on the console this should be one of:
+ - "nintendo,hollywood-otp" for the Wii
+ - "nintendo,latte-otp" for the Wii U
+- reg: base address and size of the OTP registers
+
+
+Example:
+ otp@d8001ec {
+ compatible = "nintendo,latte-otp";
+ reg = <0x0d8001ec 0x8>;
+ };
--
2.31.1
^ permalink raw reply related
* [PATCH v2 3/4] powerpc: wii.dts: Expose the OTP on this platform
From: Emmanuel Gil Peyrot @ 2021-05-19 9:50 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>
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>;
+ };
+
disk@d806000 {
compatible = "nintendo,hollywood-di";
reg = <0x0d806000 0x40>;
--
2.31.1
^ permalink raw reply related
* [PATCH v2 4/4] powerpc: wii_defconfig: Enable OTP by default
From: Emmanuel Gil Peyrot @ 2021-05-19 9:50 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>
This selects the nintendo-otp module when building for this platform, if
CONFIG_NVMEM is also selected.
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.31.1
^ permalink raw reply related
* Re: [PATCH v3 5/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Srikar Dronamraju @ 2021-05-19 12:05 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Juri Lelli, Ravi V. Shankar, linuxppc-dev, Vincent Guittot,
Tim Chen, Len Brown, Quentin Perret, Ricardo Neri, Aubrey Li,
linux-kernel, Steven Rostedt, Ricardo Neri, Ben Segall,
Ingo Molnar, Mel Gorman, Srinivas Pandruvada,
Joel Fernandes (Google), Daniel Bristot de Oliveira,
Dietmar Eggemann, Aubrey Li
In-Reply-To: <YKThlA2yZBT2KuvW@hirez.programming.kicks-ass.net>
* Peter Zijlstra <peterz@infradead.org> [2021-05-19 11:59:48]:
> On Tue, May 18, 2021 at 12:07:40PM -0700, Ricardo Neri wrote:
> > On Fri, May 14, 2021 at 07:14:15PM -0700, Ricardo Neri wrote:
> > > On Fri, May 14, 2021 at 11:47:45AM +0200, Peter Zijlstra wrote:
>
> > > > So I'm thinking that this is a property of having ASYM_PACKING at a core
> > > > level, rather than some arch special. Wouldn't something like this be
> > > > more appropriate?
>
> > > Thanks Peter for the quick review! This makes sense to me. The only
> > > reason we proposed arch_asym_check_smt_siblings() is because we were
> > > about breaking powerpc (I need to study how they set priorities for SMT,
> > > if applicable). If you think this is not an issue I can post a
> > > v4 with this update.
> >
> > As far as I can see, priorities in powerpc are set by the CPU number.
> > However, I am not sure how CPUs are enumerated? If CPUs in brackets are
> > SMT sibling, Does an enumeration looks like A) [0, 1], [2, 3] or B) [0, 2],
> > [1, 3]? I guess B is the right answer. Otherwise, both SMT siblings of a
> > core would need to be busy before a new core is used.
> >
> > Still, I think the issue described in the cover letter may be
> > reproducible in powerpc as well. If CPU3 is offlined, and [0, 2] pulled
> > tasks from [1, -] so that both CPU0 and CPU2 become busy, CPU1 would not be
> > able to help since CPU0 has the highest priority.
> >
> > I am cc'ing the linuxppc list to get some feedback.
>
> IIRC the concern with Power is that their Cores can go faster if the
> higher SMT siblings are unused.
>
> That is, suppose you have an SMT4 Core with only a single active task,
> then if only SMT0 is used it can reach max performance, but if the
> active sibling is SMT1 it can not reach max performance, and if the only
> active sibling is SMT2 it goes slower still.
>
> So they need to pack the tasks to the lowest SMT siblings, and have the
> highest SMT siblings idle (where possible) in order to increase
> performance.
>
>
If you are referring to SD_ASYM_PACKING, then packing tasks to lowest SMT
was needed in POWER7 timeframe. So if there was one thread running, then
running on the lowest sibling provided the best performance as if running in
single threaded mode.
However recent chips like POWER8/ POWER9 / POWER10 dont need SD_ASYM_PACKING
since the hardware itself does the switch. So even if task is place on a
higher sibling within the core, we dont need to switch the task to a lower
sibling for it to perform better. Now running only one thread running on any
sibling, its expected to run in single threaded mode.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
From: Segher Boessenkool @ 2021-05-19 12:03 UTC (permalink / raw)
To: Michael Ellerman
Cc: Aneesh Kumar K.V, npiggin, linux-mm, kaleshsingh, joel, akpm,
linuxppc-dev, Guenter Roeck
In-Reply-To: <20210519004514.GC10366@gate.crashing.org>
On Tue, May 18, 2021 at 07:45:14PM -0500, Segher Boessenkool wrote:
> On Wed, May 19, 2021 at 10:26:22AM +1000, Michael Ellerman wrote:
> > Guenter Roeck <linux@roeck-us.net> writes:
> > > Ah, sorry. I wasn't aware that the following is valid C code
> > >
> > > void f1()
> > > {
> > > return f2();
> > > ^^^^^^
> > > }
> > >
> > > as long as f2() is void as well. Confusing, but we live and learn.
> >
> > It might be valid, but it's still bad IMHO.
> >
> > It's confusing to readers, and serves no useful purpose.
>
> And it actually explicitly is undefined behaviour in C90 already
> (3.6.6.4 in C90, 6.8.6.4 in C99 and later).
... but there is a GCC extension that allows this by default:
<https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-type>
For C only, warn about a 'return' statement with an expression in a
function whose return type is 'void', unless the expression type is
also 'void'. As a GNU extension, the latter case is accepted
without a warning unless '-Wpedantic' is used.
Segher
^ permalink raw reply
* Re: Linux powerpc new system call instruction and ABI
From: Tulio Magno Quites Machado Filho @ 2021-05-19 12:39 UTC (permalink / raw)
To: Nicholas Piggin, Dmitry V. Levin
Cc: musl, linuxppc-dev, libc-alpha, libc-dev, linux-api
In-Reply-To: <1621421721.r9fefebis8.astroid@bobo.none>
Nicholas Piggin via Libc-alpha <libc-alpha@sourceware.org> writes:
> As a more hacky thing you could make a syscall with -1 and see how
> the error looks, and then assume all syscalls will be the same.
I'm not sure this would work.
Even in glibc, it's expected that early syscalls will use sc while scv is used
later in the execution.
--
Tulio Magno
^ permalink raw reply
* Re: Linux powerpc new system call instruction and ABI
From: Dmitry V. Levin @ 2021-05-19 13:26 UTC (permalink / raw)
To: Nicholas Piggin, Michael Ellerman
Cc: libc-alpha, Matheus Castanho, linux-api, musl, libc-dev,
linuxppc-dev
In-Reply-To: <1621421721.r9fefebis8.astroid@bobo.none>
On Wed, May 19, 2021 at 08:59:05PM +1000, Nicholas Piggin wrote:
> Excerpts from Dmitry V. Levin's message of May 19, 2021 8:24 pm:
> > On Wed, May 19, 2021 at 12:50:24PM +1000, Nicholas Piggin wrote:
> > [...]
> >> With this patch, I think the ptrace ABI should mostly be fixed. I think
> >> a problem remains with applications that look at system call return
> >> registers directly and have powerpc specific error cases. Those probably
> >> will just need to be updated unfortunately. Michael thought it might be
> >> possible to return an indication via ptrace somehow that the syscall is
> >> using a new ABI, so such apps can be updated to test for it. I don't
> >> know how that would be done.
> >
> > Is there any sane way for these applications to handle the scv case?
> > How can they tell that the scv semantics is being used for the given
> > syscall invocation? Can this information be obtained e.g. from struct
> > pt_regs?
>
> Not that I know of. Michael suggested there might be a way to add
> something. ptrace_syscall_info has some pad bytes, could
> we use one for flags bits and set a bit for "new system call ABI"?
PTRACE_GET_SYSCALL_INFO is an architecture-agnostic API, it hides all
architecture-specific details behind struct ptrace_syscall_info which has
the same meaning on all architectures. ptrace_syscall_info.exit contains
both rval and is_error fields to support every architecture regardless of
its syscall ABI.
ptrace_syscall_info.exit is extensible, but every architecture would have
to define a method of telling whether the system call follows the "new
system call ABI" conventions to export this bit of information.
This essentially means implementing something like
static inline long syscall_get_error_abi(struct task_struct *task, struct pt_regs *regs)
for every architecture, and using it along with syscall_get_error
in ptrace_get_syscall_info_exit to initialize the new field in
ptrace_syscall_info.exit structure.
> As a more hacky thing you could make a syscall with -1 and see how
> the error looks, and then assume all syscalls will be the same.
This would be very unreliable because sc and scv are allowed to intermingle,
so every syscall invocation can follow any of these two error handling
conventions.
> Or... is it possible at syscall entry to peek the address of
> the instruction which caused the call and see if that was a
> scv instruction? That would be about as reliable as possible
> without having that new flag bit.
No other architecture requires peeking into tracee memory just to find out
the syscall ABI. This would make powerpc the most ugly architecture for
ptracing.
I wonder why can't this information be just exported to the tracer via
struct pt_regs?
--
ldv
^ 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