Re: [PATCH 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform
On 09/01/2024 08:55, Chancel Liu wrote: > Add compatible string "fsl,imx95-sai" for i.MX95 platform. > > Signed-off-by: Chancel Liu > --- > Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml > b/Documentation/devicetree/bindings/sound/fsl,sai.yaml > index 088c26b001cc..f3d910aa2dc6 100644 > --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml > +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml > @@ -40,6 +40,7 @@ properties: >- fsl,imx8ulp-sai >- fsl,imx93-sai >- fsl,vf610-sai > + - fsl,imx95-sai Don't break the order, please. Best regards, Krzysztof
[PATCH v15 2/5] crash: add a new kexec flag for hotplug support
Commit a72bbec70da2 ("crash: hotplug support for kexec_load()")
introduced a new kexec flag, `KEXEC_UPDATE_ELFCOREHDR`. Kexec tool uses
this flag to indicate to the kernel that it is safe to modify the
elfcorehdr of the kdump image loaded using the kexec_load system call.
However, it is possible that architectures may need to update kexec
segments other then elfcorehdr. For example, FDT (Flatten Device Tree)
on PowerPC. Introducing a new kexec flag for every new kexec segment
may not be a good solution. Hence, a generic kexec flag bit,
`KEXEC_CRASH_HOTPLUG_SUPPORT`, is introduced to share the CPU/Memory
hotplug support intent between the kexec tool and the kernel for the
kexec_load system call.
Now, if the kexec tool sends KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag to
the kernel, it indicates to the kernel that all the required kexec
segment is skipped from SHA calculation and it is safe to update kdump
image loaded using the kexec_load syscall.
While loading the kdump image using the kexec_load syscall, the
@update_elfcorehdr member of struct kimage is set if the kexec tool
sends the KEXEC_UPDATE_ELFCOREHDR kexec flag. This member is later used
to determine whether it is safe to update elfcorehdr on hotplug events.
However, with the introduction of the KEXEC_CRASH_HOTPLUG_SUPPORT kexec
flag, the kexec tool could mark all the required kexec segments on an
architecture as safe to update. So rename the @update_elfcorehdr to
@hotplug_support. If @hotplug_support is set, the kernel can safely
update all the required kexec segments of the kdump image during
CPU/Memory hotplug events.
Introduce an architecture-specific function to process kexec flags for
determining hotplug support. Set the @hotplug_support member of struct
kimage for both kexec_load and kexec_file_load system calls. This
simplifies kernel checks to identify hotplug support for the currently
loaded kdump image by just examining the value of @hotplug_support.
Signed-off-by: Sourabh Jain
Cc: Akhil Raj
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Baoquan He
Cc: Borislav Petkov (AMD)
Cc: Boris Ostrovsky
Cc: Christophe Leroy
Cc: Dave Hansen
Cc: Dave Young
Cc: David Hildenbrand
Cc: Eric DeVolder
Cc: Greg Kroah-Hartman
Cc: Hari Bathini
Cc: Laurent Dufour
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Mimi Zohar
Cc: Naveen N Rao
Cc: Oscar Salvador
Cc: Thomas Gleixner
Cc: Valentin Schneider
Cc: Vivek Goyal
Cc: ke...@lists.infradead.org
Cc: x...@kernel.org
---
arch/x86/include/asm/kexec.h | 3 +++
arch/x86/kernel/crash.c | 18 +++---
drivers/base/cpu.c | 2 +-
drivers/base/memory.c| 2 +-
include/linux/kexec.h| 25 +++--
include/uapi/linux/kexec.h | 1 +
kernel/crash_core.c | 11 ---
kernel/kexec.c | 4 ++--
kernel/kexec_file.c | 5 +
9 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 9bb6607e864e..e791129fdf6c 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -211,6 +211,9 @@ extern void kdump_nmi_shootdown_cpus(void);
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg);
#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
+int arch_crash_hotplug_support(struct kimage *image, unsigned long
kexec_flags);
+#define arch_crash_hotplug_support arch_crash_hotplug_support
+
#ifdef CONFIG_HOTPLUG_CPU
int arch_crash_hotplug_cpu_support(void);
#define crash_hotplug_cpu_support arch_crash_hotplug_cpu_support
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 44744e9c68ec..293b54bff706 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -398,20 +398,16 @@ int crash_load_segments(struct kimage *image)
#undef pr_fmt
#define pr_fmt(fmt) "crash hp: " fmt
-/* These functions provide the value for the sysfs crash_hotplug nodes */
-#ifdef CONFIG_HOTPLUG_CPU
-int arch_crash_hotplug_cpu_support(void)
+int arch_crash_hotplug_support(struct kimage *image, unsigned long kexec_flags)
{
- return crash_check_update_elfcorehdr();
-}
-#endif
-#ifdef CONFIG_MEMORY_HOTPLUG
-int arch_crash_hotplug_memory_support(void)
-{
- return crash_check_update_elfcorehdr();
-}
+#ifdef CONFIG_KEXEC_FILE
+ if (image->file_mode)
+ return 1;
#endif
+ return (kexec_flags & KEXEC_UPDATE_ELFCOREHDR ||
+ kexec_flags & KEXEC_CRASH_HOTPLUG_SUPPORT);
+}
unsigned int arch_crash_get_elfcorehdr_size(void)
{
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 548491de818e..2f411ddfbd8b 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -306,7 +306,7 @@ static ssize_t crash_hotplug_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- return sysfs_emit(buf, "%d\n", crash_hotplug_cpu_support());
+ return sysfs_
[PATCH v15 4/5] powerpc: add crash CPU hotplug support
Due to CPU/Memory hotplug or online/offline events, the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward, CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
The current solution to address the above issue involves monitoring the
CPU/Memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
To address the aforementioned issue, commit 247262756121 ("crash: add
generic infrastructure for crash hotplug support") added a generic
infrastructure that allows architectures to selectively update the kdump
image component during CPU or memory add/remove events within the kernel
itself.
In the event of a CPU or memory add/remove events, the generic crash
hotplug event handler, `crash_handle_hotplug_event()`, is triggered. It
then acquires the necessary locks to update the kdump image and invokes
the architecture-specific crash hotplug handler,
`arch_crash_handle_hotplug_event()`, to update the required kdump image
components.
This patch adds crash hotplug handler for PowerPC and enable support to
update the kdump image on CPU add/remove events. Support for memory
add/remove events is added in a subsequent patch with the title
"powerpc: add crash memory hotplug support"
As mentioned earlier, only the elfcorehdr and FDT kdump image components
need to be updated in the event of CPU or memory add/remove events.
However, on PowerPC architecture crash hotplug handler only updates the
FDT to enable crash hotplug support for CPU add/remove events. Here's
why.
The elfcorehdr on PowerPC is built with possible CPUs, and thus, it does
not need an update on CPU add/remove events. On the other hand, the FDT
needs to be updated on CPU add events to include the newly added CPU. If
the FDT is not updated and the kernel crashes on a newly added CPU, the
kdump kernel will fail to boot due to the unavailability of the crashing
CPU in the FDT. During the early boot, it is expected that the boot CPU
must be a part of the FDT; otherwise, the kernel will raise a BUG and
fail to boot. For more information, refer to commit 36ae37e3436b0
("powerpc: Make boot_cpuid common between 32 and 64-bit"). Since it is
okay to have an offline CPU in the kdump FDT, no action is taken in case
of CPU removal.
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. Few changes have been made to ensure kernel can
safely update the FDT of kdump image loaded using both system calls.
For kexec_file_load syscall the kdump image is prepared in kernel. So to
support an increasing number of CPUs, the FDT is constructed with extra
buffer space to ensure it can accommodate a possible number of CPU
nodes. Additionally, a call to fdt_pack (which trims the unused space
once the FDT is prepared) is avoided if this feature is enabled.
For the kexec_load syscall, the FDT is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by
userspace (kexec tools). When userspace passes this flag to the kernel,
it indicates that the FDT is built to accommodate possible CPUs, and the
FDT segment is excluded from SHA calculation, making it safe to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain
Cc: Akhil Raj
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Baoquan He
Cc: Borislav Petkov (AMD)
Cc: Boris Ostrovsky
Cc: Christophe Leroy
Cc: Dave Hansen
Cc: Dave Young
Cc: David Hildenbrand
Cc: Greg Kroah-Hartman
Cc: Hari Bathini
Cc: Laurent Dufour
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Mimi Zohar
Cc: Naveen N Rao
Cc: Oscar Salvador
Cc: Thomas Gleixner
Cc: Valentin Schneider
Cc: Vivek Goyal
Cc: ke...@lists.infradead.org
Cc: x...@kernel.org
---
arch/powerpc/Kconfig | 4 ++
arch/powerpc/include/asm/kexec.h | 6 +++
arch/powerpc/kexec/core_64.c | 69 +++
arch/powerpc/kexec/elf_64.c | 12 +-
arch/powerpc/kexec/file_load_64.c | 15 +++
5 files changed, 105 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 414b978b8010..91d7bb0b81ee 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -682,6 +682,10 @@ config RELOCATABLE_TEST
config ARCH_SUPPORTS_CRASH_DUMP
def_bool PPC64 || PPC_BOOK3S_32 || PPC_85xx || (44x && !SMP)
+config
[PATCH v15 3/5] powerpc/kexec: turn some static helper functions public
Move the functions update_cpus_node and get_crash_memory_ranges from
kexec/file_load_64.c to kexec/core_64.c to make these functions usable
by other kexec components.
get_crash_memory_ranges uses functions defined in ranges.c, so take
ranges.c out of CONFIG_KEXEC_FILE.
Later in the series, these functions are utilized for in-kernel updates
to kdump image during CPU/Memory hotplug or online/offline events for
both kexec_load and kexec_file_load syscalls.
There is no intended functional change.
Signed-off-by: Sourabh Jain
Reviewed-by: Laurent Dufour
Cc: Akhil Raj
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Baoquan He
Cc: Borislav Petkov (AMD)
Cc: Boris Ostrovsky
Cc: Christophe Leroy
Cc: Dave Hansen
Cc: Dave Young
Cc: David Hildenbrand
Cc: Greg Kroah-Hartman
Cc: Hari Bathini
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Mimi Zohar
Cc: Naveen N Rao
Cc: Oscar Salvador
Cc: Thomas Gleixner
Cc: Valentin Schneider
Cc: Vivek Goyal
Cc: ke...@lists.infradead.org
Cc: x...@kernel.org
---
arch/powerpc/include/asm/kexec.h | 6 ++
arch/powerpc/kexec/Makefile | 4 +-
arch/powerpc/kexec/core_64.c | 166 ++
arch/powerpc/kexec/file_load_64.c | 162 -
4 files changed, 174 insertions(+), 164 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index e1b43aa12175..562e1bb689da 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -108,6 +108,12 @@ void crash_free_reserved_phys_range(unsigned long begin,
unsigned long end);
#endif /* CONFIG_PPC_RTAS */
#endif /* CONFIG_CRASH_DUMP */
+#ifdef CONFIG_PPC64
+struct crash_mem;
+int update_cpus_node(void *fdt);
+int get_crash_memory_ranges(struct crash_mem **mem_ranges);
+#endif /* CONFIG_PPC64 */
+
#ifdef CONFIG_KEXEC_FILE
extern const struct kexec_file_ops kexec_elf64_ops;
diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile
index 0c2abe7f9908..f2ed5b85b912 100644
--- a/arch/powerpc/kexec/Makefile
+++ b/arch/powerpc/kexec/Makefile
@@ -3,11 +3,11 @@
# Makefile for the linux kernel.
#
-obj-y += core.o crash.o core_$(BITS).o
+obj-y += core.o crash.o ranges.o core_$(BITS).o
obj-$(CONFIG_PPC32)+= relocate_32.o
-obj-$(CONFIG_KEXEC_FILE) += file_load.o ranges.o file_load_$(BITS).o
elf_$(BITS).o
+obj-$(CONFIG_KEXEC_FILE) += file_load.o file_load_$(BITS).o elf_$(BITS).o
# Disable GCOV, KCOV & sanitizers in odd or sensitive code
GCOV_PROFILE_core_$(BITS).o := n
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 762e4d09aacf..48beaadcfb70 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -30,6 +32,8 @@
#include
#include
#include
+#include
+#include
int machine_kexec_prepare(struct kimage *image)
{
@@ -376,6 +380,168 @@ void default_machine_kexec(struct kimage *image)
/* NOTREACHED */
}
+/**
+ * get_crash_memory_ranges - Get crash memory ranges. This list includes
+ * first/crashing kernel's memory regions that
+ * would be exported via an elfcore.
+ * @mem_ranges: Range list to add the memory ranges to.
+ *
+ * Returns 0 on success, negative errno on error.
+ */
+int get_crash_memory_ranges(struct crash_mem **mem_ranges)
+{
+ phys_addr_t base, end;
+ struct crash_mem *tmem;
+ u64 i;
+ int ret;
+
+ for_each_mem_range(i, &base, &end) {
+ u64 size = end - base;
+
+ /* Skip backup memory region, which needs a separate entry */
+ if (base == BACKUP_SRC_START) {
+ if (size > BACKUP_SRC_SIZE) {
+ base = BACKUP_SRC_END + 1;
+ size -= BACKUP_SRC_SIZE;
+ } else
+ continue;
+ }
+
+ ret = add_mem_range(mem_ranges, base, size);
+ if (ret)
+ goto out;
+
+ /* Try merging adjacent ranges before reallocation attempt */
+ if ((*mem_ranges)->nr_ranges == (*mem_ranges)->max_nr_ranges)
+ sort_memory_ranges(*mem_ranges, true);
+ }
+
+ /* Reallocate memory ranges if there is no space to split ranges */
+ tmem = *mem_ranges;
+ if (tmem && (tmem->nr_ranges == tmem->max_nr_ranges)) {
+ tmem = realloc_mem_ranges(mem_ranges);
+ if (!tmem)
+ goto out;
+ }
+
+ /* Exclude crashkernel region */
+ ret = crash_exclude_mem_range(tmem, crashk_res.start, crashk_res.end);
+ if (ret)
+ goto out;
+
+ /*
+* FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
+
[PATCH v15 5/5] powerpc: add crash memory hotplug support
Extend the arch crash hotplug handler, as introduced by the patch title
("powerpc: add crash CPU hotplug support"), to also support memory
add/remove events.
Elfcorehdr describes the memory of the crash kernel to capture the
kernel; hence, it needs to be updated if memory resources change due to
memory add/remove events. Therefore, arch_crash_handle_hotplug_event()
is updated to recreate the elfcorehdr and replace it with the previous
one on memory add/remove events.
The memblock list is used to prepare the elfcorehdr. In the case of
memory hot removal, the memblock list is updated after the arch crash
hotplug handler is triggered, as depicted in Figure 1. Thus, the
hot-removed memory is explicitly removed from the crash memory ranges
to ensure that the memory ranges added to elfcorehdr do not include the
hot-removed memory.
Memory remove
|
v
Offline pages
|
v
Initiate memory notify call <> crash hotplug handler
chain for MEM_OFFLINE event
|
v
Update memblock list
Figure 1
There are two system calls, `kexec_file_load` and `kexec_load`, used to
load the kdump image. A few changes have been made to ensure that the
kernel can safely update the elfcorehdr component of the kdump image for
both system calls.
For the kexec_file_load syscall, kdump image is prepared in the kernel.
To support an increasing number of memory regions, the elfcorehdr is
built with extra buffer space to ensure that it can accommodate
additional memory ranges in future.
For the kexec_load syscall, the elfcorehdr is updated only if the
KEXEC_CRASH_HOTPLUG_SUPPORT kexec flag is passed to the kernel by the
kexec tool. Passing this flag to the kernel indicates that the
elfcorehdr is built to accommodate additional memory ranges and the
elfcorehdr segment is not considered for SHA calculation, making it safe
to update.
The changes related to this feature are kept under the CRASH_HOTPLUG
config, and it is enabled by default.
Signed-off-by: Sourabh Jain
Cc: Akhil Raj
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Baoquan He
Cc: Borislav Petkov (AMD)
Cc: Boris Ostrovsky
Cc: Christophe Leroy
Cc: Dave Hansen
Cc: Dave Young
Cc: David Hildenbrand
Cc: Greg Kroah-Hartman
Cc: Hari Bathini
Cc: Laurent Dufour
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Mimi Zohar
Cc: Naveen N Rao
Cc: Oscar Salvador
Cc: Thomas Gleixner
Cc: Valentin Schneider
Cc: Vivek Goyal
Cc: ke...@lists.infradead.org
Cc: x...@kernel.org
---
arch/powerpc/include/asm/kexec.h| 5 +-
arch/powerpc/include/asm/kexec_ranges.h | 1 +
arch/powerpc/kexec/core_64.c| 107 +++-
arch/powerpc/kexec/file_load_64.c | 34 +++-
arch/powerpc/kexec/ranges.c | 85 +++
5 files changed, 225 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 943e58eb9bff..25ff5b7f1a28 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -116,8 +116,11 @@ int get_crash_memory_ranges(struct crash_mem **mem_ranges);
#ifdef CONFIG_CRASH_HOTPLUG
void arch_crash_handle_hotplug_event(struct kimage *image, void *arg);
#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
-#endif /*CONFIG_CRASH_HOTPLUG */
+unsigned int arch_crash_get_elfcorehdr_size(void);
+#define crash_get_elfcorehdr_size arch_crash_get_elfcorehdr_size
+
+#endif /*CONFIG_CRASH_HOTPLUG */
#endif /* CONFIG_PPC64 */
#ifdef CONFIG_KEXEC_FILE
diff --git a/arch/powerpc/include/asm/kexec_ranges.h
b/arch/powerpc/include/asm/kexec_ranges.h
index f83866a19e87..802abf580cf0 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++ b/arch/powerpc/include/asm/kexec_ranges.h
@@ -7,6 +7,7 @@
void sort_memory_ranges(struct crash_mem *mrngs, bool merge);
struct crash_mem *realloc_mem_ranges(struct crash_mem **mem_ranges);
int add_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
+int remove_mem_range(struct crash_mem **mem_ranges, u64 base, u64 size);
int add_tce_mem_ranges(struct crash_mem **mem_ranges);
int add_initrd_mem_range(struct crash_mem **mem_ranges);
#ifdef CONFIG_PPC_64S_HASH_MMU
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 43fcd78c2102..4673f150f973 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -19,8 +19,11 @@
#include
#include
#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -546,6 +549,101 @@ int update_cpus_node(void *fdt)
#undef pr_fmt
#define pr_fmt(fmt) "crash hp: " fmt
+/*
+ * Advertise preferred elfcorehdr size to userspace via
+ * /sys/kernel/crash_elfcorehdr_size sysfs interface.
+ */
+unsigned int arch_crash_get_elfcorehdr_size(void)
+{
+ unsigned int sz;
+ unsigned long elf_phdr_cnt;
+
+ /* Program header for CPU notes and vmcoreinfo */
+ elf_phdr_cnt = 2;
+ if (IS_ENABLED(
[PATCH v15 0/5] powerpc/crash: Kernel handling of CPU and memory hotplug
Commit 247262756121 ("crash: add generic infrastructure for crash
hotplug support") added a generic infrastructure that allows
architectures to selectively update the kdump image component during CPU
or memory add/remove events within the kernel itself.
This patch series adds crash hotplug handler for PowerPC and enable
support to update the kdump image on CPU/Memory add/remove events.
Among the 5 patches in this series, the first two patches make changes
to the generic crash hotplug handler to assist PowerPC in adding support
for this feature. The last three patches add support for this feature.
The following section outlines the problem addressed by this patch
series, along with the current solution, its shortcomings, and the
proposed resolution.
Problem:
Due to CPU/Memory hotplug or online/offline events the elfcorehdr
(which describes the CPUs and memory of the crashed kernel) and FDT
(Flattened Device Tree) of kdump image becomes outdated. Consequently,
attempting dump collection with an outdated elfcorehdr or FDT can lead
to failed or inaccurate dump collection.
Going forward CPU hotplug or online/offline events are referred as
CPU/Memory add/remove events.
Existing solution and its shortcoming:
==
The current solution to address the above issue involves monitoring the
CPU/memory add/remove events in userspace using udev rules and whenever
there are changes in CPU and memory resources, the entire kdump image
is loaded again. The kdump image includes kernel, initrd, elfcorehdr,
FDT, purgatory. Given that only elfcorehdr and FDT get outdated due to
CPU/Memory add/remove events, reloading the entire kdump image is
inefficient. More importantly, kdump remains inactive for a substantial
amount of time until the kdump reload completes.
Proposed solution:
==
Instead of initiating a full kdump image reload from userspace on
CPU/Memory hotplug and online/offline events, the proposed solution aims
to update only the necessary kdump image component within the kernel
itself.
Git tree for testing:
=
Git tree rebased on top of v6.7:
https://github.com/sourabhjains/linux/tree/kdump-in-kernel-crash-update-v15
To realize this feature, the kdump udev rule must be updated. On RHEL,
add the following two lines at the top of the
"/usr/lib/udev/rules.d/98-kexec.rules" file.
SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
With the above change to the kdump udev rule, kdump reload is avoided
during CPU/Memory add/remove events if this feature is enabled in the
kernel.
Note: only kexec_file_load syscall will work. For kexec_load minor changes
are required in kexec tool.
Changelog:
--
v15:
- Remove the patch that adds a new kexec flag for FDT update.
- Introduce a generic kexec flag bit to share hotplug support
intent between the kexec tool and the kernel for the kexec_load
syscall. (2/5)
- Introduce an architecture-specific handler to process the kexec
flag for crash hotplug support. (2/5)
- Rename the @update_elfcorehdr member of the struct kimage to
@hotplug_support. (2/5)
- Use a common function to advertise hotplug support for both CPU
and Memory. (2/5)
v14:
- Fix build warnings by including necessary header files
- Rebase to v6.7-rc5
v13:
- Fix a build warning, take ranges.c out of CONFIG_KEXEC_FILE
- Rebase to v6.7-rc4
v12:
- A patch to add new kexec flags to support this feature on kexec_load
system call
- Change in the way this feature is advertise to userspace for both
kexec_load syscall
- Rebase to v6.6-rc7
v11:
- Rebase to v6.4-rc6
- The patch that introduced CONFIG_CRASH_HOTPLUG for PowerPC has been
removed. The config is now part of common configuration:
https://lore.kernel.org/all/87ilbpflsk.fsf@mail.lhotse/
v10:
- Drop the patch that adds fdt_index attribute to struct kimage_arch
Find the fdt segment index when needed.
- Added more details into commits messages.
- Rebased onto 6.3.0-rc5
v9:
- Removed patch to prepare elfcorehdr crash notes for possible CPUs.
The patch is moved to generic patch series that introduces generic
infrastructure for in kernel crash update.
- Removed patch to pass the hotplug action type to the arch crash
hotplug handler function. The generic patch series has introduced
the hotplug action type in kimage struct.
- Add detail commit message for better understanding.
v8:
- Restrict fdt_index initialization to machine_kexec_post_load
it work for both kexec_load and kexec_file_load.[3/8] Laurent Dufour
- Updated the logic to find the number of offline core. [6/8]
- Changed the logic to find the elfcore program header to accommodate
future memory ranges due memory hotplug events. [8/8]
v7
- added a new config to configure this feature
- pass hotplug action type to arch specific
[PATCH v15 1/5] crash: forward memory_notify arg to arch crash hotplug handler
In the event of memory hotplug or online/offline events, the crash
memory hotplug notifier `crash_memhp_notifier()` receives a
`memory_notify` object but doesn't forward that object to the
generic and architecture-specific crash hotplug handler.
The `memory_notify` object contains the starting PFN (Page Frame Number)
and the number of pages in the hot-removed memory. This information is
necessary for architectures like PowerPC to update/recreate the kdump
image, specifically `elfcorehdr`.
So update the function signature of `crash_handle_hotplug_event()` and
`arch_crash_handle_hotplug_event()` to accept the `memory_notify` object
as an argument from crash memory hotplug notifier.
Since no such object is available in the case of CPU hotplug event, the
crash CPU hotplug notifier `crash_cpuhp_online()` passes NULL to the
crash hotplug handler.
Signed-off-by: Sourabh Jain
Cc: Akhil Raj
Cc: Andrew Morton
Cc: Aneesh Kumar K.V
Cc: Baoquan He
Cc: Borislav Petkov (AMD)
Cc: Boris Ostrovsky
Cc: Christophe Leroy
Cc: Dave Hansen
Cc: Dave Young
Cc: David Hildenbrand
Cc: Greg Kroah-Hartman
Cc: Hari Bathini
Cc: Laurent Dufour
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Mimi Zohar
Cc: Naveen N Rao
Cc: Oscar Salvador
Cc: Thomas Gleixner
Cc: Valentin Schneider
Cc: Vivek Goyal
Cc: ke...@lists.infradead.org
Cc: x...@kernel.org
---
arch/x86/include/asm/kexec.h | 2 +-
arch/x86/kernel/crash.c | 3 ++-
include/linux/kexec.h| 2 +-
kernel/crash_core.c | 14 +++---
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index c9f6a6c5de3c..9bb6607e864e 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -208,7 +208,7 @@ int arch_kimage_file_post_load_cleanup(struct kimage
*image);
extern void kdump_nmi_shootdown_cpus(void);
#ifdef CONFIG_CRASH_HOTPLUG
-void arch_crash_handle_hotplug_event(struct kimage *image);
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg);
#define arch_crash_handle_hotplug_event arch_crash_handle_hotplug_event
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index b6b044356f1b..44744e9c68ec 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -428,10 +428,11 @@ unsigned int arch_crash_get_elfcorehdr_size(void)
/**
* arch_crash_handle_hotplug_event() - Handle hotplug elfcorehdr changes
* @image: a pointer to kexec_crash_image
+ * @arg: struct memory_notify handler for memory hotplug case and NULL for CPU
hotplug case.
*
* Prepare the new elfcorehdr and replace the existing elfcorehdr.
*/
-void arch_crash_handle_hotplug_event(struct kimage *image)
+void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
{
void *elfbuf = NULL, *old_elfcorehdr;
unsigned long nr_mem_ranges;
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 400cb6c02176..802052d9c64b 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -483,7 +483,7 @@ static inline void arch_kexec_pre_free_pages(void *vaddr,
unsigned int pages) {
#endif
#ifndef arch_crash_handle_hotplug_event
-static inline void arch_crash_handle_hotplug_event(struct kimage *image) { }
+static inline void arch_crash_handle_hotplug_event(struct kimage *image, void
*arg) { }
#endif
int crash_check_update_elfcorehdr(void);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index d48315667752..ab1c8e79759d 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -914,7 +914,7 @@ int crash_check_update_elfcorehdr(void)
* list of segments it checks (since the elfcorehdr changes and thus
* would require an update to purgatory itself to update the digest).
*/
-static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int
cpu)
+static void crash_handle_hotplug_event(unsigned int hp_action, unsigned int
cpu, void *arg)
{
struct kimage *image;
@@ -976,7 +976,7 @@ static void crash_handle_hotplug_event(unsigned int
hp_action, unsigned int cpu)
image->hp_action = hp_action;
/* Now invoke arch-specific update handler */
- arch_crash_handle_hotplug_event(image);
+ arch_crash_handle_hotplug_event(image, arg);
/* No longer handling a hotplug event */
image->hp_action = KEXEC_CRASH_HP_NONE;
@@ -992,17 +992,17 @@ static void crash_handle_hotplug_event(unsigned int
hp_action, unsigned int cpu)
crash_hotplug_unlock();
}
-static int crash_memhp_notifier(struct notifier_block *nb, unsigned long val,
void *v)
+static int crash_memhp_notifier(struct notifier_block *nb, unsigned long val,
void *arg)
{
switch (val) {
case MEM_ONLINE:
crash_handle_hotplug_event(KEXEC_CRASH_HP_ADD_MEMORY,
- KEXEC_CRASH_HP_INVALID_CPU);
+ KEXEC_CRASH_HP_INVALID_CPU, arg);
break;
case MEM_OFFLINE:
RE: Re: [PATCH 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform
> > Add compatible string "fsl,imx95-sai" for i.MX95 platform. > > > > Signed-off-by: Chancel Liu > > --- > > Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml > b/Documentation/devicetree/bindings/sound/fsl,sai.yaml > > index 088c26b001cc..f3d910aa2dc6 100644 > > --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml > > +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml > > @@ -40,6 +40,7 @@ properties: > >- fsl,imx8ulp-sai > >- fsl,imx93-sai > >- fsl,vf610-sai > > + - fsl,imx95-sai > > Don't break the order, please. > > Best regards, > Krzysztof Sorry but I don't understand what's the "order" refer to. Could you please explain it to me? Regards, Chancel Liu
Re: [PATCH 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform
On 11/01/2024 12:06, Chancel Liu wrote: >>> Add compatible string "fsl,imx95-sai" for i.MX95 platform. >>> >>> Signed-off-by: Chancel Liu >>> --- >>> Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml >> b/Documentation/devicetree/bindings/sound/fsl,sai.yaml >>> index 088c26b001cc..f3d910aa2dc6 100644 >>> --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml >>> +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml >>> @@ -40,6 +40,7 @@ properties: >>>- fsl,imx8ulp-sai >>>- fsl,imx93-sai >>>- fsl,vf610-sai >>> + - fsl,imx95-sai >> >> Don't break the order, please. >> >> Best regards, >> Krzysztof > > Sorry but I don't understand what's the "order" refer to. Could you please > explain it to me? Items look alphabetically ordered. Best regards, Krzysztof
[PATCH v7 0/3] powerpc: make fadump resilient with memory add/remove events
Problem: Due to changes in memory resources caused by either memory hotplug or online/offline events, the elfcorehdr, which describes the cpus and memory of the crashed kernel to the kernel that collects the dump (known as second/fadump kernel), becomes outdated. Consequently, attempting dump collection with an outdated elfcorehdr can lead to failed or inaccurate dump collection. Memory hotplug or online/offline events is referred as memory add/remove events in reset of the patch series. Existing solution: == Monitor memory add/remove events in userspace using udev rules, and re-register fadump whenever there are changes in memory resources. This leads to the creation of a new elfcorehdr with updated system memory information. Challenges with existing solution: == 1. Performing bulk memory add/remove with udev-based fadump re-registration can lead to race conditions and, more importantly, it creates a large wide window during which fadump is inactive until all memory add/remove events are settled. 2. Re-registering fadump for every memory add/remove event is inefficient. 3. Memory for elfcorehdr is allocated based on the memblock regions available during first kernel early boot and it remains fixed thereafter. However, if the elfcorehdr is later recreated with additional memblock regions, its size will increase, potentially leading to memory corruption. Proposed solution: == Address the aforementioned challenges by shifting the creation of elfcorehdr from the first kernel (also referred as the crashed kernel), where it was created and frequently recreated for every memory add/remove event, to the fadump kernel. As a result, the elfcorehdr only needs to be created once, thus eliminating the necessity to re-register fadump during memory add/remove events. To know more about elfcorehdr creation in the fadump kernel, refer to the first patch in this series. The second patch includes a new sysfs interface that tells userspace that fadump re-registration isn't needed for memory add/remove events. note that userspace changes do not need to be in sync with kernel changes; they can roll out independently. Since there are significant changes in the fadump implementation, the third patch updates the fadump documentation to reflect the changes made in this patch series. Kernel tree rebased on 6.7.0-rc4 with patch series applied: = https://github.com/sourabhjains/linux/tree/fadump-mem-hotplug-v7 Userspace changes: == To realize this feature, one must update the kdump udev rules to prevent fadump re-registration during memory add/remove events. On rhel apply the following changes to file /usr/lib/udev/rules.d/98-kexec.rules -run+="/bin/sh -c '/usr/bin/systemctl is-active kdump.service || exit 0; /usr/bin/systemd-run --quiet --no-block /usr/lib/udev/kdump-udev-throttler'" +# don't re-register fadump if the value of the node +# /sys/kernel/fadump/hotplug_ready is 1. + +run+="/bin/sh -c '/usr/bin/systemctl is-active kdump.service || exit 0; ! test -f /sys/kernel/fadump_enabled || cat /sys/kernel/fadump_enabled | grep 0 || ! test -f /sys/kernel/fadump/hotplug_ready || cat /sys/kernel/fadump/hotplug_ready | grep 0 || exit 0; /usr/bin/systemd-run --quiet --no-block /usr/lib/udev/kdump-udev-throttler'" Changelog: == v7: 11 Jan 2023 - Rebase it to 6.7 v6: 8 Dec 2023 https://lore.kernel.org/all/20231208115159.82236-1-sourabhj...@linux.ibm.com/ - Add size fields for `pt_regs` and `cpumask` in the fadump header structure - Don't process the dump if the size of `pt_regs` and `cpu_mask` is not same in the crashed and fadump kernel - Include an additional check for endianness mismatch when the magic number doesn't match, to print the relevant error message - Don't process the dump if the fadump header contains an old magic number - Rebased it to 6.7.0-rc4 v5: 29 Oct 2023 https://lore.kernel.org/all/20231029124548.12198-1-sourabhj...@linux.ibm.com/ - Fix a comment on the first patch v4: 21 Oct 2023 https://lore.kernel.org/all/20231021181733.204311-1-sourabhj...@linux.ibm.com/ - Fix a build warning about type casting v3: 9 Oct 2023 https://lore.kernel.org/all/20231009041953.36139-1-sourabhj...@linux.ibm.com/ - Assign physical address of elfcorehdr to fdh->elfcorehdr_addr - Rename a variable, boot_mem_dest_addr -> boot_mem_dest_offset v2: 25 Sep 2023 https://lore.kernel.org/all/20230925051214.678957-1-sourabhj...@linux.ibm.com/ - Fixed a few indentation issues reported by the checkpatch script. - Rebased it to 6.6.0-rc3 v1: 17 Sep 2023 https://lore.kernel.org/all/20230917080225.561627-1-sourabhj...@linux.ibm.com/ Cc: Aditya Gupta Cc: Aneesh Kumar K.V Cc: Hari Bathini Cc: Mahesh Salgaonkar Cc: Michael Ellerman Cc: Naveen N Rao Sourabh Jain (3): powerpc: make fadump resilient with m
[PATCH v7 1/3] powerpc: make fadump resilient with memory add/remove events
Due to changes in memory resources caused by either memory hotplug or online/offline events, the elfcorehdr, which describes the CPUs and memory of the crashed kernel to the kernel that collects the dump (known as second/fadump kernel), becomes outdated. Consequently, attempting dump collection with an outdated elfcorehdr can lead to failed or inaccurate dump collection. Memory hotplug or online/offline events is referred as memory add/remove events in reset of the commit message. The current solution to address the aforementioned issue is as follows: Monitor memory add/remove events in userspace using udev rules, and re-register fadump whenever there are changes in memory resources. This leads to the creation of a new elfcorehdr with updated system memory information. There are several notable issues associated with re-registering fadump for every memory add/remove events. 1. Bulk memory add/remove events with udev-based fadump re-registration can lead to race conditions and, more importantly, it creates a wide window during which fadump is inactive until all memory add/remove events are settled. 2. Re-registering fadump for every memory add/remove event is inefficient. 3. The memory for elfcorehdr is allocated based on the memblock regions available during early boot and remains fixed thereafter. However, if elfcorehdr is later recreated with additional memblock regions, its size will increase, potentially leading to memory corruption. Address the aforementioned challenges by shifting the creation of elfcorehdr from the first kernel (also referred as the crashed kernel), where it was created and frequently recreated for every memory add/remove event, to the fadump kernel. As a result, the elfcorehdr only needs to be created once, thus eliminating the necessity to re-register fadump during memory add/remove events. At present, the first kernel prepares the fadump header and stores it in the fadump reserved area. The fadump header contains start address of the elfcorehd, crashing CPU details, etc. In the event of first kernel crash, the second/fadump boots and access the fadump header prepared by first kernel and do the following in a platform-specific function [rtas|opal]_fadump_process: At present, the first kernel is responsible for preparing the fadump header and storing it in the fadump reserved area. The fadump header includes the start address of the elfcorehd, crashing CPU details, and other relevant information. In the event of a crash in the first kernel, the second/fadump boots and accesses the fadump header prepared by the first kernel. It then performs the following steps in a platform-specific function [rtas|opal]_fadump_process: 1. Sanity check for fadump header 2. Update CPU notes in elfcorehdr 3. Set the global variable elfcorehdr_addr to the address of the fadump header's elfcorehdr. For vmcore module to process it later on. Along with the above, update the setup_fadump()/fadump.c to create elfcorehdr in second/fadump kernel. Section below outlines the information required to create the elfcorehdr and the changes made to make it available to the fadump kernel if it's not already. To create elfcorehdr, the following crashed kernel information is required: CPU notes, vmcoreinfo, and memory ranges. At present, the CPU notes are already prepared in the fadump kernel, so no changes are needed in that regard. The fadump kernel has access to all crashed kernel memory regions, including boot memory regions that are relocated by firmware to fadump reserved areas, so no changes for that either. However, it is necessary to add new members to the fadump header, i.e., the 'fadump_crash_info_header' structure, in order to pass the crashed kernel's vmcoreinfo address and its size to fadump kernel. In addition to the vmcoreinfo address and size, there are a few other attributes also added to the fadump_crash_info_header structure. 1. version: It stores the fadump header version, which is currently set to 1. This provides flexibility to update the fadump crash info header in the future without changing the magic number. For each change in the fadump header, the version will be increased. This will help the updated kernel determine how to handle kernel dumps from older kernels. The magic number remains relevant for checking fadump header corruption. 2. elfcorehdr_size: since elfcorehdr is now prepared in the fadump/second kernel and it is not part of the reserved area, this attribute is needed to track the memory allocated for elfcorehdr to do the deallocation properly. 3. pt_regs_sz/cpu_mask_sz: Store size of pt_regs and cpu_mask strucutre in first kernel. These attributes are used avoid processing the dump if the sizes of pt_regs and cpu_mask are not the same across the crashed and fadump kernel. Note: if either first/crashed kernel or second/fadump kernel do not have the changes introduced here then kernel fail to collec
[PATCH v7 2/3] powerpc/fadump: add hotplug_ready sysfs interface
The elfcorehdr describes the CPUs and memory of the crashed kernel to
the kernel that captures the dump, known as the second or fadump kernel.
The elfcorehdr needs to be updated if the system's memory changes due to
memory hotplug or online/offline events.
Currently, memory hotplug events are monitored in userspace by udev
rules, and fadump is re-registered, which recreates the elfcorehdr with
the latest available memory in the system.
However, the previous patch ("powerpc: make fadump resilient with memory
add/remove events") moved the creation of elfcorehdr to the second or
fadump kernel. This eliminates the need to regenerate the elfcorehdr
during memory hotplug or online/offline events.
Create a sysfs entry at /sys/kernel/fadump/hotplug_ready to let
userspace know that fadump re-registration is not required for memory
add/remove events.
Signed-off-by: Sourabh Jain
Cc: Aditya Gupta
Cc: Aneesh Kumar K.V
Cc: Hari Bathini
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Naveen N Rao
---
Documentation/ABI/testing/sysfs-kernel-fadump | 11 +++
arch/powerpc/kernel/fadump.c | 14 ++
2 files changed, 25 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump
b/Documentation/ABI/testing/sysfs-kernel-fadump
index 8f7a64a81783..8e18a6c93650 100644
--- a/Documentation/ABI/testing/sysfs-kernel-fadump
+++ b/Documentation/ABI/testing/sysfs-kernel-fadump
@@ -38,3 +38,14 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Provide information about the amount of memory reserved by
FADump to save the crash dump in bytes.
+
+What: /sys/kernel/fadump/hotplug_ready
+Date: Jan 2024
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read only
+ Kdump udev rule re-registers fadump on memory add/remove events,
+ primarily to update the elfcorehdr. This sysfs indicates the
+ kdump udev rule that fadump re-registration is not required on
+ memory add/remove events because elfcorehdr is now prepared in
+ the second/fadump kernel.
+User: kexec-tools
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index eb9132538268..a55dd9bf754c 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1455,6 +1455,18 @@ static ssize_t enabled_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
}
+/*
+ * /sys/kernel/fadump/hotplug_ready sysfs node returns 1, which inidcates
+ * to usersapce that fadump re-registration is not required on memory
+ * hotplug events.
+ */
+static ssize_t hotplug_ready_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", 1);
+}
+
static ssize_t mem_reserved_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1527,11 +1539,13 @@ static struct kobj_attribute release_attr =
__ATTR_WO(release_mem);
static struct kobj_attribute enable_attr = __ATTR_RO(enabled);
static struct kobj_attribute register_attr = __ATTR_RW(registered);
static struct kobj_attribute mem_reserved_attr = __ATTR_RO(mem_reserved);
+static struct kobj_attribute hotplug_ready_attr = __ATTR_RO(hotplug_ready);
static struct attribute *fadump_attrs[] = {
&enable_attr.attr,
®ister_attr.attr,
&mem_reserved_attr.attr,
+ &hotplug_ready_attr.attr,
NULL,
};
--
2.41.0
[PATCH v7 3/3] Documentation/powerpc: update fadump implementation details
The patch titled ("powerpc: make fadump resilient with memory add/remove
events") has made significant changes to the implementation of fadump,
particularly on elfcorehdr creation and fadump crash info header
structure. Therefore, updating the fadump implementation documentation
to reflect those changes.
Following updates are done to firmware assisted dump documentation:
1. The elfcorehdr is no longer stored after fadump HDR in the reserved
dump area. Instead, the second kernel dynamically allocates memory
for the elfcorehdr within the address range from 0 to the boot memory
size. Therefore, update figures 1 and 2 of Memory Reservation during
the first and second kernels to reflect this change.
2. A version field has been added to the fadump header to manage the
future changes to fadump crash info header structure without changing
the fadump header magic number in the future. Therefore, remove the
corresponding TODO from the document.
Signed-off-by: Sourabh Jain
Cc: Aditya Gupta
Cc: Aneesh Kumar K.V
Cc: Hari Bathini
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Cc: Naveen N Rao
---
.../arch/powerpc/firmware-assisted-dump.rst | 91 +--
1 file changed, 42 insertions(+), 49 deletions(-)
diff --git a/Documentation/arch/powerpc/firmware-assisted-dump.rst
b/Documentation/arch/powerpc/firmware-assisted-dump.rst
index e363fc48529a..7e37aadd1f77 100644
--- a/Documentation/arch/powerpc/firmware-assisted-dump.rst
+++ b/Documentation/arch/powerpc/firmware-assisted-dump.rst
@@ -134,12 +134,12 @@ that are run. If there is dump data, then the
memory is held.
If there is no waiting dump data, then only the memory required to
-hold CPU state, HPTE region, boot memory dump, FADump header and
-elfcore header, is usually reserved at an offset greater than boot
-memory size (see Fig. 1). This area is *not* released: this region
-will be kept permanently reserved, so that it can act as a receptacle
-for a copy of the boot memory content in addition to CPU state and
-HPTE region, in the case a crash does occur.
+hold CPU state, HPTE region, boot memory dump, and FADump header is
+usually reserved at an offset greater than boot memory size (see Fig. 1).
+This area is *not* released: this region will be kept permanently
+reserved, so that it can act as a receptacle for a copy of the boot
+memory content in addition to CPU state and HPTE region, in the case
+a crash does occur.
Since this reserved memory area is used only after the system crash,
there is no point in blocking this significant chunk of memory from
@@ -153,22 +153,22 @@ that were present in CMA region::
o Memory Reservation during first kernel
- Low memory Top of memory
- 0boot memory size |<--- Reserved dump area --->| |
- | | |Permanent Reservation | |
- V V || V
- +---+-/ /---+---++---+-+-++--+
- | | |///|| DUMP | HDR | ELF || |
- +---+-/ /---+---++---+-+-++--+
-| ^^ ^ ^ ^
-| || | | |
-\ CPU HPTE / | |
- -- | |
- Boot memory content gets transferred| |
- to reserved area by firmware at the | |
- time of crash. | |
- FADump Header |
- (meta area)|
+ Low memory Top of memory
+ 0boot memory size |<-- Reserved dump area ->| |
+ | | | Permanent Reservation | |
+ V V | | V
+ +---+-/ /---+---++---+---++-+
+ | | |///||DUMP | HDR || |
+ +---+-/ /---+---++---+---++-+
+| ^^ ^ ^ ^
+| || | | |
+\ CPU HPTE / | |
+ | |
+ Boot memory content gets transferred | |
+ to reserved area by firmware at the | |
+ time of crash. | |
+ FADump Header |
+(meta area) |
|
|
Metadata: This area holds a metadata structure whose
@@ -186,13 +186,20 @@ that were present in CMA
Re: [PATCH v5 0/5] RISC-V SBI debug console extension support
Hello: This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt : On Fri, 24 Nov 2023 12:39:00 +0530 you wrote: > The SBI v2.0 specification is now frozen. The SBI v2.0 specification defines > SBI debug console (DBCN) extension which replaces the legacy SBI v0.1 > functions sbi_console_putchar() and sbi_console_getchar(). > (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases) > > This series adds support for SBI debug console (DBCN) extension in > Linux RISC-V. > > [...] Here is the summary with links: - [v5,1/5] RISC-V: Add stubs for sbi_console_putchar/getchar() https://git.kernel.org/riscv/c/f503b167b660 - [v5,2/5] RISC-V: Add SBI debug console helper routines https://git.kernel.org/riscv/c/f43fabf444ca - [v5,3/5] tty/serial: Add RISC-V SBI debug console based earlycon https://git.kernel.org/riscv/c/c77bf3607a0f - [v5,4/5] tty: Add SBI debug console support to HVC SBI driver https://git.kernel.org/riscv/c/88ead68e764c - [v5,5/5] RISC-V: Enable SBI based earlycon support https://git.kernel.org/riscv/c/50942ad6ddb5 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH v5] powerpc/pseries/vas: Use usleep_range() to support HCALL delay
Haren Myneni writes:
> VAS allocate, modify and deallocate HCALLs returns
> H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC for busy
> delay and expects OS to reissue HCALL after that delay. But using
> msleep() will often sleep at least 20 msecs even though the
> hypervisor suggests OS reissue these HCALLs after 1 or 10msecs.
>
> The open and close VAS window functions hold mutex and then issue
> these HCALLs. So these operations can take longer than the
> necessary when multiple threads issue open or close window APIs
> simultaneously, especially might affect the performance in the
> case of repeat open/close APIs for each compression request.
> On the large machine configuration which allows more simultaneous
> open/close windows (Ex: 240 cores provides 4800 VAS credits), the
> user can observe hung task traces in dmesg due to mutex contention
> around open/close HCAlls.
Is this because the workload queues enough tasks on the mutex to trigger
the hung task watchdog? With a threshold of 120 seconds, something on
the order of ~6000 tasks each taking 20ms or more to traverse this
critical section would cause the problem I think you're describing.
Presumably this change improves the situation, but the commit message
isn't explicit. Have you measured the "throughput" of window open/close
activity before and after? Anything that quantifies the improvement
would be welcome.
> diff --git a/arch/powerpc/platforms/pseries/vas.c
> b/arch/powerpc/platforms/pseries/vas.c
> index 71d52a670d95..79ffe8868c04 100644
> --- a/arch/powerpc/platforms/pseries/vas.c
> +++ b/arch/powerpc/platforms/pseries/vas.c
> @@ -38,7 +38,27 @@ static long hcall_return_busy_check(long rc)
> {
> /* Check if we are stalled for some time */
> if (H_IS_LONG_BUSY(rc)) {
> - msleep(get_longbusy_msecs(rc));
> + unsigned int ms;
> + /*
> + * Allocate, Modify and Deallocate HCALLs returns
> + * H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC
> + * for the long delay. So the sleep time should always
> + * be either 1 or 10msecs, but in case if the HCALL
> + * returns the long delay > 10 msecs, clamp the sleep
> + * time to 10msecs.
> + */
> + ms = clamp(get_longbusy_msecs(rc), 1, 10);
> +
> + /*
> + * msleep() will often sleep at least 20 msecs even
> + * though the hypervisor suggests that the OS reissue
> + * HCALLs after 1 or 10msecs. Also the delay hint from
> + * the HCALL is just a suggestion. So OK to pause for
> + * less time than the hinted delay. Use usleep_range()
> + * to ensure we don't sleep much longer than actually
> + * needed.
> + */
> + usleep_range(ms * 100, ms * USEC_PER_MSEC);
usleep_range(ms * (USEC_PER_MSEC / 10), ms * USEC_PER_MSEC);
is probably what reviewers want to see when they ask you to use
USEC_PER_MSEC. I.e. both arguments to usleep_range() should be expressed
in terms of USEC_PER_MSEC.
Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
Hi Yonghong,
On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
>
> On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > has been abandoned in favor of GitHub pull requests. While the majority
> > of links in the kernel sources still work because of the work Fangrui
> > has done turning the dynamic Phabricator instance into a static archive,
> > there are some issues with that work, so preemptively convert all the
> > links in the kernel sources to point to the commit on GitHub.
> >
> > Most of the commits have the corresponding differential review link in
> > the commit message itself so there should not be any loss of fidelity in
> > the relevant information.
> >
> > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > in the area.
> >
> > Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > Signed-off-by: Nathan Chancellor
>
> Ack with one nit below.
>
> Acked-by: Yonghong Song
> > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > .. code-block:: console
> > - test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073?
> > unexpected error: -4007
> > + test_xdpwall:FAIL:Does LLVM have
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > unexpected error: -4007
> > -__ https://reviews.llvm.org/D109073
> > +__
> > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
>
> To be consistent with other links, could you add the missing last alnum '5'
> to the above link?
Thanks a lot for catching this and providing an ack. Andrew, could you
squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
diff --git a/tools/testing/selftests/bpf/README.rst
b/tools/testing/selftests/bpf/README.rst
index b9a493f66557..e56034abb3c2 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -306,4 +306,4 @@ from running test_progs will look like:
test_xdpwall:FAIL:Does LLVM have
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
unexpected error: -4007
-__
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
+__
https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5
Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor wrote:
>
> Hi Yonghong,
>
> On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> >
> > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > has been abandoned in favor of GitHub pull requests. While the majority
> > > of links in the kernel sources still work because of the work Fangrui
> > > has done turning the dynamic Phabricator instance into a static archive,
> > > there are some issues with that work, so preemptively convert all the
> > > links in the kernel sources to point to the commit on GitHub.
> > >
> > > Most of the commits have the corresponding differential review link in
> > > the commit message itself so there should not be any loss of fidelity in
> > > the relevant information.
> > >
> > > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > > in the area.
> > >
> > > Link:
> > > https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > > Signed-off-by: Nathan Chancellor
> >
> > Ack with one nit below.
> >
> > Acked-by: Yonghong Song
>
>
>
> > > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > > .. code-block:: console
> > > - test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073?
> > > unexpected error: -4007
> > > + test_xdpwall:FAIL:Does LLVM have
> > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > > unexpected error: -4007
> > > -__ https://reviews.llvm.org/D109073
> > > +__
> > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> >
> > To be consistent with other links, could you add the missing last alnum '5'
> > to the above link?
>
> Thanks a lot for catching this and providing an ack. Andrew, could you
> squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
Please send a new patch.
We'd like to take all bpf patches through the bpf tree to avoid conflicts.
Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
Hi Alexei,
On Thu, Jan 11, 2024 at 12:00:50PM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor wrote:
> >
> > Hi Yonghong,
> >
> > On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote:
> > >
> > > On 1/9/24 2:16 PM, Nathan Chancellor wrote:
> > > > reviews.llvm.org was LLVM's Phabricator instances for code review. It
> > > > has been abandoned in favor of GitHub pull requests. While the majority
> > > > of links in the kernel sources still work because of the work Fangrui
> > > > has done turning the dynamic Phabricator instance into a static archive,
> > > > there are some issues with that work, so preemptively convert all the
> > > > links in the kernel sources to point to the commit on GitHub.
> > > >
> > > > Most of the commits have the corresponding differential review link in
> > > > the commit message itself so there should not be any loss of fidelity in
> > > > the relevant information.
> > > >
> > > > Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
> > > > in the area.
> > > >
> > > > Link:
> > > > https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
> > > > Signed-off-by: Nathan Chancellor
> > >
> > > Ack with one nit below.
> > >
> > > Acked-by: Yonghong Song
> >
> >
> >
> > > > @@ -304,6 +304,6 @@ from running test_progs will look like:
> > > > .. code-block:: console
> > > > - test_xdpwall:FAIL:Does LLVM have https://reviews.llvm.org/D109073?
> > > > unexpected error: -4007
> > > > + test_xdpwall:FAIL:Does LLVM have
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d5?
> > > > unexpected error: -4007
> > > > -__ https://reviews.llvm.org/D109073
> > > > +__
> > > > https://github.com/llvm/llvm-project/commit/ea72b0319d7b0f0c2fcf41d121afa5d031b319d
> > >
> > > To be consistent with other links, could you add the missing last alnum
> > > '5' to the above link?
> >
> > Thanks a lot for catching this and providing an ack. Andrew, could you
> > squash this update into selftests-bpf-update-llvm-phabricator-links.patch?
>
> Please send a new patch.
> We'd like to take all bpf patches through the bpf tree to avoid conflicts.
Very well, I've sent a standalone v2 on top of bpf-next:
https://lore.kernel.org/20240111-bpf-update-llvm-phabricator-links-v2-1-9a7ae976b...@kernel.org/
Andrew, just drop selftests-bpf-update-llvm-phabricator-links.patch
altogether in that case, the other two patches are fine to go via -mm I
think.
Cheers,
Nathan
Re: [PATCH 0/3] Update LLVM Phabricator and Bugzilla links
On Wed, Jan 10, 2024 at 4:46 PM Kees Cook wrote: > > On Tue, Jan 09, 2024 at 03:16:28PM -0700, Nathan Chancellor wrote: > > This series updates all instances of LLVM Phabricator and Bugzilla links > > to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue > > shortlinks respectively. > > > > I split up the Phabricator patch into BPF selftests and the rest of the > > kernel in case the BPF folks want to take it separately from the rest of > > the series, there are obviously no dependency issues in that case. The > > Bugzilla change was mechanical enough and should have no conflicts. > > > > I am aiming this at Andrew and CC'ing other lists, in case maintainers > > want to chime in, but I think this is pretty uncontroversial (famous > > last words...). > > > > --- > > Nathan Chancellor (3): > > selftests/bpf: Update LLVM Phabricator links > > arch and include: Update LLVM Phabricator links > > treewide: Update LLVM Bugzilla links > > > > arch/arm64/Kconfig | 4 +-- > > arch/powerpc/Makefile | 4 +-- > > arch/powerpc/kvm/book3s_hv_nested.c| 2 +- > > arch/riscv/Kconfig | 2 +- > > arch/riscv/include/asm/ftrace.h| 2 +- > > arch/s390/include/asm/ftrace.h | 2 +- > > arch/x86/power/Makefile| 2 +- > > crypto/blake2b_generic.c | 2 +- > > drivers/firmware/efi/libstub/Makefile | 2 +- > > drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- > > drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- > > drivers/regulator/Kconfig | 2 +- > > include/asm-generic/vmlinux.lds.h | 2 +- > > include/linux/compiler-clang.h | 2 +- > > lib/Kconfig.kasan | 2 +- > > lib/raid6/Makefile | 2 +- > > lib/stackinit_kunit.c | 2 +- > > mm/slab_common.c | 2 +- > > net/bridge/br_multicast.c | 2 +- > > security/Kconfig | 2 +- > > tools/testing/selftests/bpf/README.rst | 32 > > +++--- > > tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- > > .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- > > 23 files changed, 40 insertions(+), 40 deletions(-) > > --- > > base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a > > change-id: 20240109-update-llvm-links-d03f9d649e1e > > > > Best regards, > > -- > > Nathan Chancellor > > > > Excellent! Thanks for doing this. I spot checked a handful I was > familiar with and everything looks good to me. > > Reviewed-by: Kees Cook > > -- > Kees Cook > These reviews.llvm.org links would definitely be kept like https://lists.llvm.org/pipermail/llvm-dev/ or cfe-dev links (discussions have been migrated to Discourse). However, I agree that the github repo link looks more official. I have clicked a few links and they look good. Since I maintain reviews.llvm.org and created the static archive [1], Acked-by: Fangrui Song [1]: https://discourse.llvm.org/t/llvm-phabricator-turndown/76137 -- 宋方睿
[PATCH RFC] powerpc/pseries: exploit H_PAGE_SET_UNUSED for partition migration
From: Nathan Lynch
Although the H_PAGE_INIT hcall's H_PAGE_SET_UNUSED historically has
been tied to the cooperative memory overcommit (CMO) platform feature,
the flag also is treated by the PowerVM hypervisor as a hint that the
page contents need not be copied to the destination during a live
partition migration.
Use the "ibm,migratable-partition" root node property to determine
whether this partition/guest can be migrated. Mark freed pages unused
if so (or if CMO is in use, as before).
Signed-off-by: Nathan Lynch
---
Several things yet to improve here:
* powerpc's arch_free_page()/HAVE_ARCH_FREE_PAGE should be decoupled
from CONFIG_PPC_SMLPAR.
* powerpc's arch_free_page() could be made to use a static key if
justified.
* I have not yet measured the overhead this introduces, nor have I
measured the benefit to a live migration.
To date, I have smoke tested it by doing a live migration and
performing a build on a kernel with the change, to ensure it doesn't
introduce obvious memory corruption or anything. It hasn't blown up
yet :-)
This will be a possibly significant behavior change in that we will be
flagging pages unused where we typically did not before. Until now,
having CMO enabled was the only way to do this, and I don't think that
feature is used all that much?
Posting this as RFC to see if there are any major concerns.
---
arch/powerpc/platforms/pseries/lpar.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 4561667832ed..b264371d8e12 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1772,17 +1773,25 @@ static void pSeries_set_page_state(struct page *page,
int order,
}
}
+static bool migratable_partition;
+
void arch_free_page(struct page *page, int order)
{
- if (radix_enabled())
- return;
- if (!cmo_free_hint_flag || !firmware_has_feature(FW_FEATURE_CMO))
- return;
-
- pSeries_set_page_state(page, order, H_PAGE_SET_UNUSED);
+ if (migratable_partition ||
+ (firmware_has_feature(FW_FEATURE_CMO) && cmo_free_hint_flag))
+ pSeries_set_page_state(page, order, H_PAGE_SET_UNUSED);
}
EXPORT_SYMBOL(arch_free_page);
+static int __init check_migratable_partition(void)
+{
+ struct device_node *root = of_find_node_by_path("/");
+ migratable_partition = !!of_find_property(root,
"ibm,migratable-partition", NULL);
+ of_node_put(root);
+ return 0;
+}
+machine_device_initcall(pseries, check_migratable_partition);
+
#endif /* CONFIG_PPC_SMLPAR */
#endif /* CONFIG_PPC_BOOK3S_64 */
---
base-commit: 44a1aad2fe6c10bfe0589d8047057b10a4c18a19
change-id: 20240111-h_page_set_unused-for-lpm-d9027c672fe8
Best regards,
--
Nathan Lynch
Re: PowerNV PCIe hotplug support?
On Thu, Dec 28, 2023 at 3:16 PM Timothy Pearson wrote: > > I've been evaluating some new options for our POWER9-based hardware in the > NVMe space, and would like some clarification on the current status of PCIe > hotplug for the PowerNV platforms. > > From what I understand, the pnv_php driver provides the basic hotplug > functionality on PowerNV. What I'm not clear on is to what extent this is > intended to flow downstream to attached PCIe switches. I did a bunch of work on NVMe hotplug back in the day and it worked fine then. Most of that work was done with Gen3 PLX switches though which are considerably dumber than the newer ones though. > I have a test setup here that consists of a PMC 8533 switch and several > downstream NVMe drives, with the switch attached directly to the PHB4 root > port. After loading the pnv_php module, I can disconnect the downstream NVMe > devices by either using echo 0 on /sys/bus/pcu/slots/Snnn/power, or by > doing a physical surprise unplug, however nothing I try can induce a newly > plugged device to train and be detected on the bus. Even trying a echo 0 and > subsequent echo 1 to /sys/bus/pcu/slots/Snnn/power only results in the > device going offline, there seems to be no way to bring the device back > online short of a reboot. > > Hotplug of other devices connected directly to the PHB4 appears to work > properly (I can online and offline via the power node); the issue seems to be > restricted to downstream devices connected to the (theoretically hotplug > capable) PMC 8533 switch. I'd suspect either the PCIe interrupt is not being delivered for some reason (EEH might be isolating the PCIe switch port?) or the removal is triggering downstream port containment on the switch. Check the port capability status with lspci. IIRC pnv_php doesn't know anything about DPC so you might need to have skiboot disable that by default to keep the kernel happy. > Is this the intended behavior for downstream (non-IBM) PCIe ports? Raptor > can provide resources to assist in a fix if needed, but I would like to > understand if this is a bug or an unimplemented feature first, and if the > latter what the main issues are likely to be in implementation. It *should* work and the WARN()/BUG() spew you're seeing are bugs that just need fixing. That said, hotplug on PNV is a headache for a bunch of reasons most of which are due to EEH. Something I was working towards before I left IBM was refactoring how EEH worked internally so we could eliminate the need for pnv_php and go back to using the standard pcieport driver. Unfortunately, that's a big job and I can't even remember how much of that work actually made it upstream.
Re: PowerNV PCIe hotplug support?
On Thu, Dec 28, 2023 at 4:49 PM Timothy Pearson wrote: > > Hrmm, potentially related, I'm getting a kernel oops when I try to hot unplug > the entire PCIe switch from the PHB4: IIRC there's hard to fix races in the pci core around removal of pci slot devices. Maybe someone fixed those since I tried last, but I'd just avoid doing that if I were you.
[PATCH v2 0/3] ASoC: Support SAI and MICFIL on i.MX95 platform
Support SAI and MICFIL on i.MX95 platform changes in v2 - Remove unnecessary "item" in fsl,micfil.yaml - Don't change alphabetical order in fsl,sai.yaml Chancel Liu (3): ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform ASoC: fsl_sai: Add support for i.MX95 platform ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform .../devicetree/bindings/sound/fsl,micfil.yaml | 14 ++ .../devicetree/bindings/sound/fsl,sai.yaml | 1 + sound/soc/fsl/fsl_sai.c| 13 + 3 files changed, 24 insertions(+), 4 deletions(-) -- 2.42.0
[PATCH v2 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform
Add compatible string "fsl,imx95-sai" for i.MX95 platform. Signed-off-by: Chancel Liu --- Documentation/devicetree/bindings/sound/fsl,sai.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml index 088c26b001cc..d81c8fe1893e 100644 --- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml @@ -39,6 +39,7 @@ properties: - fsl,imx8qm-sai - fsl,imx8ulp-sai - fsl,imx93-sai + - fsl,imx95-sai - fsl,vf610-sai reg: -- 2.42.0
[PATCH v2 2/3] ASoC: fsl_sai: Add support for i.MX95 platform
Add compatible string and specific soc data to support SAI on i.MX95
platform.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_sai.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 546bd4e333b5..0e2c31439670 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1639,6 +1639,18 @@ static const struct fsl_sai_soc_data fsl_sai_imx93_data
= {
.max_burst = {8, 8},
};
+static const struct fsl_sai_soc_data fsl_sai_imx95_data = {
+ .use_imx_pcm = true,
+ .use_edma = true,
+ .fifo_depth = 128,
+ .reg_offset = 8,
+ .mclk0_is_mclk1 = false,
+ .pins = 8,
+ .flags = 0,
+ .max_register = FSL_SAI_MCTL,
+ .max_burst = {8, 8},
+};
+
static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,vf610-sai", .data = &fsl_sai_vf610_data },
{ .compatible = "fsl,imx6sx-sai", .data = &fsl_sai_imx6sx_data },
@@ -1651,6 +1663,7 @@ static const struct of_device_id fsl_sai_ids[] = {
{ .compatible = "fsl,imx8ulp-sai", .data = &fsl_sai_imx8ulp_data },
{ .compatible = "fsl,imx8mn-sai", .data = &fsl_sai_imx8mn_data },
{ .compatible = "fsl,imx93-sai", .data = &fsl_sai_imx93_data },
+ { .compatible = "fsl,imx95-sai", .data = &fsl_sai_imx95_data },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fsl_sai_ids);
--
2.42.0
[PATCH v2 3/3] ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform
Add compatible string "fsl,imx95-micfil" for i.MX95 platform. Signed-off-by: Chancel Liu --- .../devicetree/bindings/sound/fsl,micfil.yaml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml index b7e605835639..c1e9803fc113 100644 --- a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,micfil.yaml @@ -15,10 +15,16 @@ description: | properties: compatible: -enum: - - fsl,imx8mm-micfil - - fsl,imx8mp-micfil - - fsl,imx93-micfil +oneOf: + - items: + - enum: + - fsl,imx95-micfil + - const: fsl,imx93-micfil + + - enum: + - fsl,imx8mm-micfil + - fsl,imx8mp-micfil + - fsl,imx93-micfil reg: maxItems: 1 -- 2.42.0
[PATCH v2] cxl: Fix null pointer dereference in cxl_get_fd
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Uniformly handle resource release in error paths. And when an
error occurs, an error pointer should be returned.
Fixes: bdecf76e319a ("cxl: Fix coredump generation when cxl_get_fd() is used")
Signed-off-by: Kunwu Chan
Cc: Kunwu Chan
Suggested-by: Frederic Barrat
---
v2: Deal with error path
---
drivers/misc/cxl/api.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index d85c56530863..b49bc3d29fc0 100644
--- a/drivers/misc/cxl/api.c
+++ b/drivers/misc/cxl/api.c
@@ -389,19 +389,22 @@ struct file *cxl_get_fd(struct cxl_context *ctx, struct
file_operations *fops,
int *fd)
{
struct file *file;
- int rc, flags, fdtmp;
+ int rc = 0, flags, fdtmp;
char *name = NULL;
/* only allow one per context */
- if (ctx->mapping)
- return ERR_PTR(-EEXIST);
+ if (ctx->mapping) {
+ rc = -EEXIST;
+ goto err;
+ }
flags = O_RDWR | O_CLOEXEC;
/* This code is similar to anon_inode_getfd() */
rc = get_unused_fd_flags(flags);
if (rc < 0)
- return ERR_PTR(rc);
+ goto err;
+
fdtmp = rc;
/*
@@ -419,6 +422,10 @@ struct file *cxl_get_fd(struct cxl_context *ctx, struct
file_operations *fops,
fops = (struct file_operations *)&afu_fops;
name = kasprintf(GFP_KERNEL, "cxl:%d", ctx->pe);
+ if (!name) {
+ rc = -ENOMEM;
+ goto err_fd;
+ }
file = cxl_getfile(name, fops, ctx, flags);
kfree(name);
if (IS_ERR(file))
@@ -430,6 +437,9 @@ struct file *cxl_get_fd(struct cxl_context *ctx, struct
file_operations *fops,
err_fd:
put_unused_fd(fdtmp);
+err:
+ if (rc < 0)
+ return ERR_PTR(rc);
return NULL;
}
EXPORT_SYMBOL_GPL(cxl_get_fd);
--
2.39.2
Re: [PATCH v2 1/3] ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX95 platform
On 12/01/2024 06:43, Chancel Liu wrote: > Add compatible string "fsl,imx95-sai" for i.MX95 platform. > > Signed-off-by: Chancel Liu > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 3/3] ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX95 platform
On 12/01/2024 06:43, Chancel Liu wrote: > Add compatible string "fsl,imx95-micfil" for i.MX95 platform. > > Signed-off-by: Chancel Liu Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
