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
ext 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: [46bb5dd1d2a63e906e374e
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
---
Documentation/PCI/pci-error-recovery.rst | 25
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
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
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
On Thu, Jul 1, 2021 at 12:32 PM Naveen N. Rao
wrote:
>
> Alexei Starovoitov wrote:
> > On Thu, Jul 1, 2021 at 8:09 AM 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
Alexei Starovoitov wrote:
On Thu, Jul 1, 2021 at 8:09 AM 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
Christophe Leroy wrote:
Le 01/07/2021 à 17:08, Naveen N. Rao a écrit :
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
On Sat, Jun 26, 2021 at 11:34:01PM +, 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
> > ---
> > arch/powerpc/boot/dts/wii.dts | 5
Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
> On Wed Jun 30, 2021 at 11:15 PM CDT, Nicholas Piggin wrote:
>> Excerpts from Christopher M. Riedl's message of July 1, 2021 1:48 pm:
>> > On Sun Jun 20, 2021 at 10:13 PM CDT, Daniel Axtens wrote:
>> >> "Christopher M. Riedl"
On Thu Jul 1, 2021 at 1:12 AM CDT, Nicholas Piggin wrote:
> Excerpts from Christopher M. Riedl's message of May 6, 2021 2:34 pm:
> > When code patching a STRICT_KERNEL_RWX kernel the page containing the
> > address to be patched is temporarily mapped as writeable. Currently, a
> > per-cpu vmalloc
cpu_cpu_map holds all the CPUs in the DIE. However in PowerPC, when
onlining/offlining of CPUs, this mask doesn't get updated. This mask
is however updated when CPUs are added/removed. So when both
operations like online/offline of CPUs and adding/removing of CPUs are
done simultaneously, then
Currently, a debug message gets printed every time an attempt to
add(remove) a CPU. However this is redundant if the CPU is already added
(removed) from the node.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Nathan Lynch
Cc: Michael Ellerman
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Valentin Schneider
Excerpts from Christopher M. Riedl's message of May 6, 2021 2:34 pm:
> When code patching a STRICT_KERNEL_RWX kernel the page containing the
> address to be patched is temporarily mapped as writeable. Currently, a
> per-cpu vmalloc patch area is used for this purpose. While the patch
> area is
On Thu Jul 1, 2021 at 1:04 AM CDT, Nicholas Piggin wrote:
> Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
> > On Wed Jun 30, 2021 at 11:15 PM CDT, Nicholas Piggin wrote:
> >> Excerpts from Christopher M. Riedl's message of July 1, 2021 1:48 pm:
> >> > On Sun Jun 20, 2021 at
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > > `BUG: unable to handle page fault for address: 003a8290` and
> > > the fact it crashed
Excerpts from Christopher M. Riedl's message of July 1, 2021 4:53 pm:
> On Thu Jul 1, 2021 at 1:04 AM CDT, Nicholas Piggin wrote:
>> Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
>> > On Wed Jun 30, 2021 at 11:15 PM CDT, Nicholas Piggin wrote:
>> >> Excerpts from
Excerpts from Christopher M. Riedl's message of July 1, 2021 5:02 pm:
> On Thu Jul 1, 2021 at 1:12 AM CDT, Nicholas Piggin wrote:
>> Excerpts from Christopher M. Riedl's message of May 6, 2021 2:34 pm:
>> > When code patching a STRICT_KERNEL_RWX kernel the page containing the
>> > address to be
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 29/04/2021 à 19:49, Laurent Dufour a écrit :
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 11/05/2021 à 09:31, Laurent Dufour a écrit :
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead the number of NUMA node from the actual system.
The DT property
Hi Michael,
Do you mind taking this patch of 5.14?
Thanks,
Laurent.
Le 17/05/2021 à 11:06, Laurent Dufour a écrit :
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is
Excerpts from Fabiano Rosas's message of July 1, 2021 3:51 am:
> Nicholas Piggin writes:
>
>> Some of the DAWR SPR access is already predicated on dawr_enabled(),
>> apply this to the remainder of the accesses.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>>
When simultaneously running CPU online/offline with CPU add/remove in a
loop, we see a WARNING messages.
WARNING: CPU: 13 PID: 1142 at kernel/sched/topology.c:898
build_sched_domains+0xd48/0x1720
Modules linked in: rpadlpar_io rpaphp mptcp_diag xsk_diag tcp_diag udp_diag
raw_diag inet_diag
Hello,
This series adds support for MSI IRQ domains on top of the XICS (P8)
and XIVE (P9/P10) IRQ domains for the PowerNV (baremetal) and pSeries
(VM) platforms. It should simplify and improve IRQ affinity of PCI
MSIs under these PowerPC platforms, specially for drivers distributing
multiple
Two IRQ domains are added on top of default machine IRQ domain.
First, the top level "pSeries-PCI-MSI" domain deals with the MSI
specificities. In this domain, the HW IRQ numbers are generated by the
PCI MSI layer, they compose a unique ID for an MSI source with the PCI
device identifier and the
pr_debug() is easier to activate and it helps to know how the kernel
configures the HW when tweaking the IRQ subsystem.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
The MSI domain clears the IRQ with msi_domain_free(), which calls
irq_domain_free_irqs_top(), which clears the handler data. This is a
problem for the XIVE controller since we need to unmap MMIO pages and
free a specific XIVE structure.
The 'msi_free()' handler is called before
pnv_opal_pci_msi_eoi() is called from KVM to EOI passthrough interrupts
when in real mode. Adding MSI domain broke the hack using the
'ioda.irq_chip' field to deduce the owning PHB. Fix that by using the
IRQ chip data in the MSI domain.
The 'ioda.irq_chip' field is now unused and could be removed
desc->irq_data points to the top level IRQ data descriptor which is
not necessarily in the XICS IRQ domain. MSIs are in another domain for
instance. Fix that by looking for a mapping on the low level XICS IRQ
domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 9
MSIs should be fully managed by the PCI and IRQ subsystems now.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci.h | 6 --
arch/powerpc/platforms/powernv/pci-ioda.c | 27 -
arch/powerpc/platforms/powernv/pci.c | 67 ---
3 files
On Thu, Jul 1, 2021 at 2:57 PM Christophe Leroy
wrote:
> Le 01/07/2021 à 14:50, Jason Wang a écrit :
> > The BUG_ON macro simplifies the if condition followed by BUG, but it
> > will lead to the kernel crashing. Therefore, we can try using WARN_ON
> > instead of if condition followed by BUG.
>
>
Excerpts from Nicholas Piggin's message of July 1, 2021 5:37 pm:
> Excerpts from Christopher M. Riedl's message of July 1, 2021 4:53 pm:
>> On Thu Jul 1, 2021 at 1:04 AM CDT, Nicholas Piggin wrote:
>>> Excerpts from Christopher M. Riedl's message of July 1, 2021 3:28 pm:
>>> > On Wed Jun 30, 2021
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
Le 01/07/2021 à 14:50, Jason Wang a écrit :
The BUG_ON macro simplifies the if condition followed by BUG, but it
will lead to the kernel crashing. Therefore, we can try using WARN_ON
instead of if condition followed by BUG.
But are you sure it is ok to continue if spu_acquire(ctx) returned
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
It will help to size the PCI MSI domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c
b/arch/powerpc/platforms/pseries/msi.c
index
It will be used as a 'compose_msg' handler of the MSI domain introduced
later.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 28 +++
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
This is very similar to the MSI domains of the pSeries platform. The
MSI allocator is directly handled under the Linux PHB in the
in-the-middle "PNV-MSI" domain.
Only the XIVE (P9/P10) parent domain is supported for now. Support for
XICS will come later.
Signed-off-by: Cédric Le Goater
---
Passthrough PCI MSI interrupts are detected in KVM with a check on a
specific EOI handler (P8) or on XIVE (P9). We can now check the
PCI-MSI IRQ chip which is cleaner.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c
The RTAS firmware can not disable one MSI at a time. It's all or
nothing. We need a custom free IRQ handler for that.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 16
1 file changed, 16 insertions(+)
diff --git
This moves the IRQ initialization done under the different ICS backends
in the common part of XICS. The 'map' handler becomes a simple 'check'
on the HW IRQ at the FW level.
As we don't need an ICS anymore in xics_migrate_irqs_away(), the XICS
domain does not set a chip data for the IRQ.
XICS doesn't have any state associated with the IRQ. The support is
straightforward and simpler than for XIVE.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 41 ++
1 file changed, 41 insertions(+)
diff --git
It really helps to know how the HW is configured when tweaking the IRQ
subsystem.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/ics-opal.c | 2 +-
arch/powerpc/sysdev/xics/ics-rtas.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git
On 01/07/21 09:45, Srikar Dronamraju wrote:
> @@ -1891,12 +1894,30 @@ void sched_init_numa(void)
> void sched_domains_numa_masks_set(unsigned int cpu)
> {
> int node = cpu_to_node(cpu);
> - int i, j;
> + int i, j, empty;
>
> + empty =
In the early days of XIVE support, commit cffb717ceb8e ("powerpc/xive:
Ensure active irqd when setting affinity") tried to fix an issue
related to interrupt migration. If the root cause was related to CPU
unplug, it should have been fixed and there is no reason to keep the
irqd_is_started() check.
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
The ARRAY_SIZE macro is more compact and formal to get array size in
linux kernel source. In addition, it is more readable for kernel
developpers. Thus, we can replace all sizeof(arr)/sizeof(arr[0]) with
ARRAY_SIZE.
Signed-off-by: Jason Wang
---
arch/powerpc/xmon/ppc-opc.c | 16 ++--
The BUG_ON macro simplifies the if condition followed by BUG, but it
will lead to the kernel crashing. Therefore, we can try using WARN_ON
instead of if condition followed by BUG.
Signed-off-by: Jason Wang
---
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
1 file changed, 2 insertions(+),
The pnv_ioda2_msi_eoi() chip handler is not used anymore for MSIs.
Simply use the check on the PSI-MSI chip.
Cc: Alexey Kardashevskiy
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The routine kvmppc_set_passthru_irq() calls kvmppc_xive_set_mapped()
and kvmppc_xive_clr_mapped() with an IRQ descriptor. Use directly the
host IRQ number to remove a useless conversion.
Add some debug.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/kvm_ppc.h | 4 ++--
That was a workaround in the XICS domain because of the lack of MSI
domain. This is now handled.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/ics-opal.c | 11 ---
arch/powerpc/sysdev/xics/ics-rtas.c | 9 -
2 files changed, 20 deletions(-)
diff --git
The default domain of the PCI/MSIs is not the XIVE domain anymore. To
list the IRQ mappings under XMON and debugfs, query the IRQ data from
the low level XIVE domain.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 11 +--
1 file changed, 5 insertions(+), 6
PCI MSIs now live in an MSI domain but the underlying calls, which
will EOI the interrupt in real mode, need an HW IRQ number mapped in
the XICS IRQ domain. Grab it there.
Cc: Alexey Kardashevskiy
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_hv.c | 12 ++--
1 file
The PowerNV and pSeries platforms now have support for both the XICS
and XIVE IRQ domains.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 +---
arch/powerpc/platforms/pseries/msi.c | 4
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git
We always had only one ICS per machine. Simplify the XICS driver by
removing the ICS list.
The ICS stored in the chip data of the XICS domain becomes useless and
we don't need it anymore to migrate away IRQs from a CPU. This will be
removed in a subsequent patch.
Signed-off-by: Cédric Le Goater
This splits the routine setting the MSIs in two parts: allocation of
MSIs for the PCI device at the FW level (RTAS) and the actual mapping
and activation of the IRQs.
rtas_prepare_msi_irqs() will serve as a handler for the PCI MSI domain.
Signed-off-by: Cédric Le Goater
---
and clean up the error path.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xics/xics-common.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/xics/xics-common.c
b/arch/powerpc/sysdev/xics/xics-common.c
index
Before MSI domains, the default IRQ chip of PHB3 MSIs was patched by
pnv_set_msi_irq_chip() with the custom EOI handler pnv_ioda2_msi_eoi()
and the owning PHB was deduced from the 'ioda.irq_chip' field. This
path has been deprecated by the MSI domains but it is still in use by
the P8 CAPI 'cxl'
The HW IRQ numbers generated by the PCI MSI layer can be quite large
on a pSeries machine when running under the IBM Hypervisor and they
appear as negative. Use '%lu' instead to show them correctly.
Cc: Thomas Gleixner
Signed-off-by: Cédric Le Goater
---
kernel/irq/irqdesc.c | 2 +-
PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
underlying calls handling the passthrough of the interrupt in the
guest need a number in the XIVE IRQ domain.
Use the IRQ data mapped in the XIVE IRQ domain and not the one in the
PCI-MSI domain.
Cc: Thomas Gleixner
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.
Signed-off-by: Jason Wang
---
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
MSIs should be fully managed by the PCI and IRQ subsystems now.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/msi.c | 87
1 file changed, 87 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c
b/arch/powerpc/platforms/pseries/msi.c
This adds handlers to allocate/free IRQs in a domain hierarchy. We
could try to use xive_irq_domain_map() in xive_irq_domain_alloc() but
we rely on xive_irq_alloc_data() to set the IRQ handler data and
duplicating the code is simpler.
xive_irq_free_data() needs to be called when IRQ are freed to
PHB3s need an extra OPAL call to EOI the interrupt. The call takes an
OPAL HW IRQ number but it is translated into a vector number in OPAL.
Here, we directly use the vector number of the in-the-middle "PNV-MSI"
domain instead of grabbing the OPAL HW IRQ number in the XICS parent
domain.
Simply allocate or release the MSI domains when a PHB is inserted in
or removed from the machine.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/platforms/pseries/pseries.h | 1 +
arch/powerpc/platforms/pseries/msi.c | 10 ++
arch/powerpc/platforms/pseries/pci_dlpar.c | 4
That was a workaround in the XIVE domain because of the lack of MSI
domain. This is now handled.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/sysdev/xive/common.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c
The first patch fixes an issue that causes a soft lockup on ppc64 with
the BPF_ATOMIC bounds propagation verifier test. The second one updates
ppc32 JIT to reject atomic operations properly.
- Naveen
Naveen N. Rao (2):
powerpc/bpf: Fix detecting BPF atomic instructions
powerpc/bpf: Reject
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
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
different from BPF_ADD. However, ppc32 BPF JIT was implemented around
the same time
This is a smatch warning:
arch/powerpc/sysdev/xive/common.c:1161 xive_request_ipi() warn: unsigned
'xid->irq' is never less than zero.
Fixes: fd6db2892eba ("powerpc/xive: Modernize XIVE-IPI domain with an 'alloc'
handler")
Cc: sta...@vger.kernel.org # v5.13
Reported-by: kernel test robot
On Thu, Jul 1, 2021 at 8:09 AM 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
Le 01/07/2021 à 17:08, Naveen N. Rao a écrit :
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
different from BPF_ADD.
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
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
>
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
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
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
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
---
.../bindings/nvmem/nintendo-otp.yaml | 44
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
0x0d80 and spans 0x400 bytes (that is, 0x100 32-bit registers),
encompassing PIC and
This can be used by the newly-added nintendo-otp nvmem module.
Signed-off-by: Emmanuel Gil Peyrot
---
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
This selects the nintendo-otp module when building for this platform.
Signed-off-by: Emmanuel Gil Peyrot
---
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
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
83 matches
Mail list logo
