* [PATCH] powerpc: wii: Add the fixed OTP layout
@ 2026-07-26 18:19 Link Mauve
2026-07-26 18:30 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Link Mauve @ 2026-07-26 18:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Link Mauve, J. Neuschäfer, techflashYT, Ash Logan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), devicetree, linuxppc-dev,
linux-kernel
These 128 bytes have a known fixed layout, so we can expose those as
cells for either kernel or userspace consumption.
Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
---
arch/powerpc/boot/dts/wii.dts | 38 +++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 473d9feb9cdb..0d1806273d43 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -233,6 +233,44 @@ control@d800100 {
otp@d8001ec {
compatible = "nintendo,hollywood-otp";
reg = <0x0d8001ec 0x8>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ boot1_sha1@0 {
+ reg = <0x00 0x14>;
+ };
+
+ common_key@14 {
+ reg = <0x14 0x10>;
+ };
+
+ device_id@24 {
+ reg = <0x24 0x4>;
+ };
+
+ device_private_key@28 {
+ reg = <0x28 0x1c>;
+ };
+
+ nand_hmac_key@44 {
+ reg = <0x44 0x14>;
+ };
+
+ nand_key@58 {
+ reg = <0x58 0x10>;
+ };
+
+ backup_key@68 {
+ reg = <0x68 0x10>;
+ };
+
+ unknown@78 {
+ reg = <0x78 0x8>;
+ };
+ };
};
disk@d806000 {
base-commit: 9eebf259d5352b87080d67758f483583d9e763d7
--
2.55.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] powerpc: wii: Add the fixed OTP layout
2026-07-26 18:19 [PATCH] powerpc: wii: Add the fixed OTP layout Link Mauve
@ 2026-07-26 18:30 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-07-26 18:30 UTC (permalink / raw)
To: Link Mauve; +Cc: robh, conor+dt, devicetree
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] Device tree node names use underscores instead of hyphens, which will trigger `dtc` build warnings.
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but concurrent reads from the NVMEM driver lead to interleaved I/O operations and corrupted data returns.
--
--- Patch [1]: [PATCH] powerpc: wii: Add the fixed OTP layout ---
commit 50a0e49ef16272487c2bdbc82035d4dd0bfb8e87
Author: Link Mauve <linkmauve@linkmauve.fr>
powerpc: wii: Add the fixed OTP layout
This commit exposes the 128-byte fixed layout of the Wii OTP as cells
for either kernel or userspace consumption.
> diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
> index 473d9feb9cdb8..0d1806273d43c 100644
> --- a/arch/powerpc/boot/dts/wii.dts
> +++ b/arch/powerpc/boot/dts/wii.dts
> @@ -233,6 +233,44 @@ control@d800100 {
> otp@d8001ec {
> compatible = "nintendo,hollywood-otp";
> reg = <0x0d8001ec 0x8>;
> +
> + nvmem-layout {
> + compatible = "fixed-layout";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + boot1_sha1@0 {
[Severity: Low]
This isn't a bug, but does using underscores in device tree node names
violate standard devicetree naming conventions?
It looks like this will trigger dtc build warnings when compiling with strict
checking enabled, such as "Character '_' not recommended in node name".
Would it be better to use hyphens here, for example boot1-sha1@0?
[ ... ]
While looking at how these new cells are consumed by the NVMEM subsystem,
I noticed a behavior in the underlying provider code:
drivers/nvmem/nintendo-otp.c:nintendo_otp_reg_read() {
...
iowrite32be(OTP_READ | bank | addr, priv->regs + HW_OTPCMD);
*val++ = ioread32be(priv->regs + HW_OTPDATA);
...
}
[Severity: High]
This is a pre-existing issue and was not introduced by this patch, but
is there a missing lock around this two-step I/O sequence?
If two threads concurrently read from the NVMEM provider, could their
command and data I/O register accesses interleave?
For example:
Thread A writes to HW_OTPCMD.
Thread B preempts, writes to HW_OTPCMD, and reads HW_OTPDATA.
Thread A resumes and reads HW_OTPDATA, incorrectly receiving Thread B's data.
Since the NVMEM core does not serialize reg_read callbacks, should the
provider implement locking to prevent silent data corruption on concurrent
accesses?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260726181921.16269-1-linkmauve@linkmauve.fr?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-07-26 18:30 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-26 18:19 [PATCH] powerpc: wii: Add the fixed OTP layout Link Mauve
2026-07-26 18:30 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox