Re: [PATCH] powerpc/fadump: re-register firmware-assisted dump if already registered

2018-09-14 Thread Petr Tesarik
On Fri, 14 Sep 2018 19:36:02 +0530 Hari Bathini wrote: > Firmware-Assisted Dump (FADump) needs to be registered again after any > memory hot add/remove operation to update the crash memory ranges. But > currently, the kernel returns '-EEXIST' if we try to register without > uregistering it first.

Re: [PATCH 01/11] kexec_file: allow archs to handle special regions while locating memory hole

2020-06-29 Thread Petr Tesarik
Hi Hari, is there any good reason to add two more functions with a very similar name to an existing function? AFAICS all you need is a way to call a PPC64-specific function from within kexec_add_buffer (PATCH 4/11), so you could add something like this: int __weak arch_kexec_locate_mem_hole(struc

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-12 Thread Petr Tesarik
On Tue, 12 Jul 2016 13:25:11 -0300 Thiago Jung Bauermann wrote: > Hi Eric, > > I'm trying to understand your concerns leading to your nack. I hope you > don't mind expanding your thoughts on them a bit. > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > > AKASHI Takahiro wri

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-12 Thread Petr Tesarik
On Tue, 12 Jul 2016 16:22:07 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Petr Tesarik writes: > > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann wrote: >[...] > >> I also don't understand what you mean by code execution. How doe

Re: [RFC 0/3] extend kexec_file_load system call

2016-07-13 Thread Petr Tesarik
Linux writes: > > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > > >> >> I'm not an expert on DTB, so I can't provide an example of code > > >> >> execution, but you have already mentioned the > > >>

Re: [PATCH v2] Document/kexec: Generalize crash hotplug description

2024-08-11 Thread Petr Tesarik
> Therefore, update the relevant kernel documentation to reflect the same. > > No functional change. > > Cc: Petr Tesarik > Cc: Hari Bathini > Cc: ke...@lists.infradead.org > Cc: linux-ker...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: x...@kernel.org

Re: [PATCH v6 RESED 1/2] dma: replace zone_dma_bits by zone_dma_limit

2024-08-11 Thread Petr Tesarik
address for DMA zone limit. > > Since DMA zone can now potentially span beyond 4GB physical limit of > DMA32, make sure to use DMA zone for GFP_DMA32 allocations in that case. > > Signed-off-by: Catalin Marinas > Co-developed-by: Baruch Siach > Signed-off-by: Baruch Siach

Re: [PATCH v6 RESED 2/2] arm64: support DMA zone above 4GB

2024-08-11 Thread Petr Tesarik
iginal patch] > Signed-off-by: Baruch Siach Note that I'm not an Arm64 maintainer, so the value of my review is limited, but AFAICS this change should work as intended. Reviewed-by: Petr Tesarik Petr T > --- > arch/arm64/mm/init.c | 12 > 1 file changed, 12 del