Move update_cpus_node and get_crash_memory_ranges functions from
kexec/file_load_64.c to kexec/core_64.c to make these functions usable
by other kexec components.
Later in the series, these functions are utilized to do in-kernel update
to kexec segments on CPU/Memory hot plug/unplug or online/offl
Due to CPU/Memory hot plug/unplug or online/offline events the system
resources changes. A similar change should reflect in the loaded kdump
kernel kexec segments that describes the state of the CPU and memory of
the running kernel.
If the kdump kernel kexec segments are not updated after the CPU/
The Problem:
Post CPU/Memory hot plug/unplug and online/offline events the kernel
holds stale information about the system. Dump collection with stale
kdump kernel might end up in dump capture failure or an inaccurate dump
collection.
Existing solution:
==
The existin
Introduce powerpc crash hotplug handler to update the necessary kexec
segments in the kernel on CPU/Memory hotplug events. Currently, these
updates are done by monitoring CPU/Memory hotplug events in userspace.
A common crash hotplug handler is triggered from generic infrastructure
for both CPU/Me
On PowePC memblock regions are used to prepare elfcorehdr which
describes the memory regions of the running kernel to the kdump kernel.
Since the notifier used for the memory hotplug crash handler gets
initiated before the update of the memblock region happens (as depicted
below) the newly prepared
Extend PowerPC arch crash hotplug handler to support memory hotplug
events. Since elfcorehdr is used to exchange the memory info between the
kernels hence it needs to be recreated to reflect the changes due to
memory hotplug events.
The way memory hotplug events are handled on PowerPC and the noti
On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote:
> On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote:
> >
> > Dear PowerPC and RCU developers:
> > During the RCU torture test on mainline (on the VM of Opensource Lab
> > of Oregon State University), SRCU-P failed with __stack_chk_fai
Hi Mark
These are v2 patch-set of asoc_dummy_dlc.
Many ASoC drivers are using dummy DAI.
I have 2 concern about it. 1st one is there is no guarantee that local
strings ("snd-soc-dummy-dai", "snd-soc-dummy") are kept until the card
was binded if it was added at subfunction.
2nd one is we can us
Now we can share asoc_dummy_dlc. This patch use it.
Signed-off-by: Kuninori Morimoto
---
sound/soc/fsl/imx-audmix.c | 14 +-
sound/soc/fsl/imx-card.c | 11 +--
sound/soc/fsl/imx-rpmsg.c | 3 +--
sound/soc/fsl/imx-spdif.c | 8 +++-
4 files changed, 10 insertions(+),
Thank Boqun for your wonderful analysis!
On Mon, Apr 24, 2023 at 8:33 AM Boqun Feng wrote:
>
> On Sat, Apr 22, 2023 at 09:28:39PM +0200, Joel Fernandes wrote:
> > On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote:
> > >
> > > Dear PowerPC and RCU developers:
> > > During the RCU torture test on
PCIe service that shares IRQ with PME may cause spurious wakeup on
system suspend.
PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
that TLP and DLLP transmission is disabled for a Link in L2/L3 Ready
(D3hot), L2 (D3cold with aux power) and L3 (D3cold), so we don't lose
much he
There are many places that enable and disable AER interrput, so move
them into helpers.
Reviewed-by: Mika Westerberg
Reviewed-by: Kuppuswamy Sathyanarayanan
Signed-off-by: Kai-Heng Feng
---
drivers/pci/pcie/aer.c | 45 +-
1 file changed, 27 insertions(+
PCIe service that shares IRQ with PME may cause spurious wakeup on
system suspend.
Since AER is conditionally disabled in previous patch, also apply the
same logic to disable DPC which depends on AER to work.
PCIe Base Spec 5.0, section 5.2 "Link State Power Management" states
that TLP and DLLP t
13 matches
Mail list logo
