Re: [PATCH v4 4/4] PCI: layerscape: Add suspend/resume for ls1043a

2023-11-30 Thread Manivannan Sadhasivam
On Thu, Nov 30, 2023 at 03:22:14PM -0500, Frank Li wrote: > On Thu, Nov 30, 2023 at 03:17:39PM -0500, Frank Li wrote: > > On Thu, Nov 30, 2023 at 10:21:00PM +0530, Manivannan Sadhasivam wrote: > > > On Wed, Nov 29, 2023 at 04:44:12PM -0500, Frank Li wrote: > > > > In the suspend path, PME_Turn_Off

Re: [PATCH v2] powerpc/pseries/vas: Use usleep_range() to support HCALL delay

2023-11-30 Thread Haren Myneni
On 11/29/23 6:07 PM, Michael Ellerman wrote: 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

[powerpc:fixes] BUILD SUCCESS dc158d23b33df9033bcc8e7117e8591dd2f9d125

2023-11-30 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes branch HEAD: dc158d23b33df9033bcc8e7117e8591dd2f9d125 KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers elapsed time: 1203m configs tested: 166 configs skipped: 90 The following configs have

Re: linux-next: build failure after merge of the mm tree

2023-11-30 Thread Michael Ellerman
Andrew Morton writes: > On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman > wrote: > >> > I am still carrying this patch (it should probably go into the mm >> > tree). Is someone going to pick it up (assuming it is correct)? >> >> I applied it to my next a few days ago, but I must have

Re: [PATCH v4 4/4] PCI: layerscape: Add suspend/resume for ls1043a

2023-11-30 Thread Manivannan Sadhasivam
On Thu, Nov 30, 2023 at 03:17:39PM -0500, Frank Li wrote: > On Thu, Nov 30, 2023 at 10:21:00PM +0530, Manivannan Sadhasivam wrote: > > On Wed, Nov 29, 2023 at 04:44:12PM -0500, Frank Li wrote: > > > In the suspend path, PME_Turn_Off message is sent to the endpoint to > > > transition the link to

[PATCH] powerpc/44x: select I2C for CURRITUCK

2023-11-30 Thread Randy Dunlap
Fix build errors when CURRITUCK=y and I2C is not builtin (=m or is not set). Fixes these build errors: powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `avr_halt_system': ppc476.c:(.text+0x58): undefined reference to `i2c_smbus_write_byte_data' powerpc-linux-ld:

Re: [PATCH v2] powerpc/pseries/vas: Use usleep_range() to support HCALL delay

2023-11-30 Thread Haren Myneni
On 11/29/23 5:43 PM, Nathan Lynch wrote: 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

Re: [PATCH] powerpc/mm: Fix null-pointer dereference in pgtable_cache_add

2023-11-30 Thread Kunwu Chan
Thanks for your reply. Ok, I know what you mean, when name is NULL. The process should be aborted and the specific reason for the error should be printed, not just return. I will update v2 patch with "panic". Thanks again, Kunwu On 2023/11/28 19:32, Michael Ellerman wrote: Kunwu Chan

Re: [PATCH 5/5] powerpc/64s: Fix CONFIG_NUMA=n build

2023-11-30 Thread Arnd Bergmann
On Thu, Nov 30, 2023, at 07:43, Michael Ellerman wrote: > "Arnd Bergmann" writes: >> On Wed, Nov 29, 2023, at 14:19, Michael Ellerman wrote: >>> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h >>> index 7f9ff0640124..72341b9fb552 100644 >>> --- a/arch/powerpc/mm/mmu_decl.h

[PATCH v2] powerpc/mm: Fix null-pointer dereference in pgtable_cache_add

2023-11-30 Thread Kunwu Chan
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Suggested-by: Christophe Leroy Suggested-by: Michael Ellerman Signed-off-by: Kunwu Chan --- v2: Use "panic" instead of "return"

Re: [kvm-unit-tests PATCH v1 00/18] arm/arm64: Rework cache maintenance at boot

2023-11-30 Thread Alexandru Elisei
Hi, Thank you so much for reviving this, much appreciated. I wanted to let you know that I definitely plan to review the series as soon as possible, unfortunately I don't believe I won't be able to do that for at least 2 weeks. Thanks, Alex On Thu, Nov 30, 2023 at 04:07:02AM -0500, Shaoqin

Re: Ping? Re: [PATCH rc] kvm: Prevent compiling virt/kvm/vfio.c unless VFIO is selected

2023-11-30 Thread Jason Gunthorpe
On Wed, Nov 29, 2023 at 06:02:08PM -0800, Sean Christopherson wrote: > > > Ah, it's the same warning, I just missed the CONFIG_MODULES=n requirement. > > > > Oh, wait, doesn't that mean the approach won't work? IIRC doesn't > > symbol_get turn into just when non-modular turning this into a > >

[PATCH] powerpc/irq: Allow softirq to hardirq stack transition

2023-11-30 Thread Michael Ellerman
Allow a transition from the softirq stack to the hardirq stack when handling a hardirq. Doing so means a hardirq received while deep in softirq processing is less likely to cause a stack overflow of the softirq stack. Previously it wasn't safe to do so because irq_exit() (which initiates softirq

[PATCH 1/2] powerpc/mm: Fix build failures due to arch_reserved_kernel_pages()

2023-11-30 Thread Michael Ellerman
With NUMA=n and FA_DUMP=y or PRESERVE_FA_DUMP=y the build fails with: arch/powerpc/kernel/fadump.c:1739:22: error: no previous prototype for ‘arch_reserved_kernel_pages’ [-Werror=missing-prototypes] 1739 | unsigned long __init arch_reserved_kernel_pages(void) |

[kvm-unit-tests PATCH v1 02/18] powerpc: Replace the physical allocator with the page allocator

2023-11-30 Thread Shaoqin Huang
From: Alexandru Elisei The spapr_hcall test makes two page sized allocations using the physical allocator. Replace the physical allocator with the page allocator, which has has more features (like support for freeing allocations), and would allow for further simplification of the physical

Re: [PATCH v2 1/3] powerpc/code-patching: Add generic memory patching

2023-11-30 Thread Naveen N Rao
On Mon, Oct 16, 2023 at 04:01:45PM +1100, Benjamin Gray wrote: > patch_instruction() is designed for patching instructions in otherwise > readonly memory. Other consumers also sometimes need to patch readonly > memory, so have abused patch_instruction() for arbitrary data patches. > > This is a

Re: [PATCH] perf test record+probe_libc_inet_pton: Fix call chain match on powerpc

2023-11-30 Thread Likhitha Korrapati
Hi Arnaldo, Thank you for pointing it. From next time I will take care of it. -Likhitha. On 30/11/23 02:26, Arnaldo Carvalho de Melo wrote: Em Sun, Nov 26, 2023 at 02:09:14AM -0500, Likhitha Korrapati escreveu: The perf test "probe libc's inet_pton & backtrace it with ping" fails on powerpc

[kvm-unit-tests PATCH v1 00/18] arm/arm64: Rework cache maintenance at boot

2023-11-30 Thread Shaoqin Huang
Hi, I'm posting Alexandru's patch set[1] rebased on the latest branch with the conflicts being resolved. No big changes compare to its original code. As this version 1 of this series was posted one years ago, I would first let you recall it, what's the intention of this series and what this

[kvm-unit-tests PATCH v1 01/18] Makefile: Define __ASSEMBLY__ for assembly files

2023-11-30 Thread Shaoqin Huang
From: Alexandru Elisei There are 25 header files today (found with grep -r "#ifndef __ASSEMBLY__) with functionality relies on the __ASSEMBLY__ prepocessor constant being correctly defined to work correctly. So far, kvm-unit-tests has relied on the assembly files to define the constant before

Re: [PATCH v2 2/3] powerpc/64: Convert patch_instruction() to patch_u32()

2023-11-30 Thread Naveen N Rao
On Mon, Oct 16, 2023 at 04:01:46PM +1100, Benjamin Gray wrote: > This use of patch_instruction() is working on 32 bit data, and can fail > if the data looks like a prefixed instruction and the extra write > crosses a page boundary. Use patch_u32() to fix the write size. > > Fixes: 8734b41b3efe

[PATCH 2/2] powerpc: Fix build error due to is_valid_bugaddr()

2023-11-30 Thread Michael Ellerman
With CONFIG_GENERIC_BUG=n the build fails with: arch/powerpc/kernel/traps.c:1442:5: error: no previous prototype for ‘is_valid_bugaddr’ [-Werror=missing-prototypes] 1442 | int is_valid_bugaddr(unsigned long addr) | ^~~~ The prototype is only defined, and the function

Re: [PATCH 1/2] kexec: fix KEXEC_FILE dependencies

2023-11-30 Thread Eric DeVolder
On 11/30/23 10:56, Andrew Morton wrote: On Thu, 2 Nov 2023 16:03:18 +0800 Baoquan He wrote: CONFIG_KEXEC_FILE, but still get purgatory code built in which is totally useless. Not sure if I think too much over this. I see your point here, and I would suggest changing the

Re: [PATCH] scsi: ibmvfc: replace deprecated strncpy with strscpy

2023-11-30 Thread Kees Cook
On Mon, Oct 30, 2023 at 07:04:33PM +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect these fields to be NUL-terminated as the property names from >

Re: [PATCH] scsi: ibmvscsi: replace deprecated strncpy with strscpy

2023-11-30 Thread Kees Cook
On Mon, Oct 30, 2023 at 08:40:48PM +, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We expect partition_name to be NUL-terminated based on its usage with >

Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing

2023-11-30 Thread Peter Xu
On Fri, Nov 24, 2023 at 11:07:51AM -0500, Peter Xu wrote: > On Fri, Nov 24, 2023 at 09:06:01AM +, Ryan Roberts wrote: > > I don't have any micro-benchmarks for GUP though, if that's your question. > > Is > > there an easy-to-use test I can run to get some numbers? I'd be happy to > > try it

Re: [PATCH v4 05/13] powerpc/rtas: Facilitate high-level call sequences

2023-11-30 Thread Nathan Lynch
Nathan Lynch writes: > Alternatively, sys_rtas() could be refactored into locking and > non-locking paths, e.g. > > static long __do_sys_rtas(struct rtas_function *func) > { > // [ ... acquire rtas_lock, enter RTAS, fetch any error etc ... ] > } Of course this conflicts with the code

Re: linux-next: build failure after merge of the mm tree

2023-11-30 Thread Stephen Rothwell
Hi all, On Mon, 27 Nov 2023 14:48:52 +1100 Stephen Rothwell wrote: > > Just cc'ing the PowerPC guys to see if my fix is sensible. > > On Mon, 27 Nov 2023 13:28:09 +1100 Stephen Rothwell > wrote: > > > > After merging the mm tree, today's linux-next build (powerpc64 > > allnoconfig) failed

Re: linux-next: build failure after merge of the mm tree

2023-11-30 Thread Andrew Morton
On Fri, 1 Dec 2023 09:04:39 +1100 Stephen Rothwell wrote: > Hi all, > > > > diff --git a/arch/powerpc/mm/book3s64/pgtable.c > > > b/arch/powerpc/mm/book3s64/pgtable.c > > > index be229290a6a7..3438ab72c346 100644 > > > --- a/arch/powerpc/mm/book3s64/pgtable.c > > > +++

Re: linux-next: build failure after merge of the mm tree

2023-11-30 Thread Michael Ellerman
Stephen Rothwell writes: > On Mon, 27 Nov 2023 14:48:52 +1100 Stephen Rothwell > wrote: >> >> Just cc'ing the PowerPC guys to see if my fix is sensible. >> >> On Mon, 27 Nov 2023 13:28:09 +1100 Stephen Rothwell >> wrote: >> > >> > After merging the mm tree, today's linux-next build

Re: [PATCH v4 05/13] powerpc/rtas: Facilitate high-level call sequences

2023-11-30 Thread Michael Ellerman
Nathan Lynch writes: > Michael Ellerman writes: >> Nathan Lynch writes: >>> Michael Ellerman writes: Nathan Lynch via B4 Relay writes: > From: Nathan Lynch > > On RTAS platforms there is a general restriction that the OS must not > enter RTAS on more than one CPU at

Re: linux-next: build failure after merge of the mm tree

2023-11-30 Thread Andrew Morton
On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman wrote: > > I am still carrying this patch (it should probably go into the mm > > tree). Is someone going to pick it up (assuming it is correct)? > > I applied it to my next a few days ago, but I must have forgotten to > push. It's in there

Re: [PATCH v4 2/4] PCI: layerscape: Add suspend/resume for ls1021a

2023-11-30 Thread Manivannan Sadhasivam
On Wed, Nov 29, 2023 at 04:44:10PM -0500, Frank Li wrote: > ls1021a add suspend/resume support. > "Add suspend/resume support for Layerscape LS1021a" > In the suspend path, PME_Turn_Off message is sent to the endpoint to > transition the link to L2/L3_Ready state. In this SoC, there is no way

Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec register save

2023-11-30 Thread Timothy Pearson
- Original Message - > From: "Michael Ellerman" > To: "Timothy Pearson" > Cc: "Jens Axboe" , "regressions" > , "npiggin" , > "christophe leroy" , "linuxppc-dev" > > Sent: Tuesday, November 28, 2023 6:57:01 AM > Subject: Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec

Re: [PATCH v4 3/4] PCI: layerscape: Rename pf_* as pf_lut_*

2023-11-30 Thread Manivannan Sadhasivam
On Wed, Nov 29, 2023 at 04:44:11PM -0500, Frank Li wrote: > 'pf' and 'lut' is just difference name in difference chips, but basic it is > a MMIO base address plus an offset. > > Rename it to avoid duplicate pf_* and lut_* in driver. > > Signed-off-by: Frank Li Reviewed-by: Manivannan

Re: [PATCH v4 4/4] PCI: layerscape: Add suspend/resume for ls1043a

2023-11-30 Thread Manivannan Sadhasivam
On Wed, Nov 29, 2023 at 04:44:12PM -0500, Frank Li wrote: > In the suspend path, PME_Turn_Off message is sent to the endpoint to > transition the link to L2/L3_Ready state. In this SoC, there is no way to > check if the controller has received the PME_To_Ack from the endpoint or > not. So to be on

Re: [PATCH] powerpc/irq: Allow softirq to hardirq stack transition

2023-11-30 Thread Christophe Leroy
Le 30/11/2023 à 13:50, Michael Ellerman a écrit : > Allow a transition from the softirq stack to the hardirq stack when > handling a hardirq. Doing so means a hardirq received while deep in > softirq processing is less likely to cause a stack overflow of the > softirq stack. > > Previously it

Re: [PATCH 1/2] kexec: fix KEXEC_FILE dependencies

2023-11-30 Thread Andrew Morton
On Thu, 2 Nov 2023 16:03:18 +0800 Baoquan He wrote: > > > CONFIG_KEXEC_FILE, but still get purgatory code built in which is > > > totally useless. > > > > > > Not sure if I think too much over this. > > > > I see your point here, and I would suggest changing the > >

Re: [PATCH 2/3] powerpc/pseries/memhp: Remove unbalanced dlpar_release_drc() call

2023-11-30 Thread Scott Cheloha
> On Nov 28, 2023, at 9:21 AM, Nathan Lynch wrote: > > Nick Child writes: >> Hi Nathan, >> Patches 1 and 3 LGTM > > thanks. > >> Regarding this patch, dlpar_memory_remove_by_count() calls >> dlpar_add_lmb() and does not free drc on add error. >> dlpar_add_lmb() is called here in error

Re: [PATCH v4 4/4] PCI: layerscape: Add suspend/resume for ls1043a

2023-11-30 Thread Frank Li
On Thu, Nov 30, 2023 at 10:21:00PM +0530, Manivannan Sadhasivam wrote: > On Wed, Nov 29, 2023 at 04:44:12PM -0500, Frank Li wrote: > > In the suspend path, PME_Turn_Off message is sent to the endpoint to > > transition the link to L2/L3_Ready state. In this SoC, there is no way to > > check if the

Re: [PATCH v4 4/4] PCI: layerscape: Add suspend/resume for ls1043a

2023-11-30 Thread Frank Li
On Thu, Nov 30, 2023 at 03:17:39PM -0500, Frank Li wrote: > On Thu, Nov 30, 2023 at 10:21:00PM +0530, Manivannan Sadhasivam wrote: > > On Wed, Nov 29, 2023 at 04:44:12PM -0500, Frank Li wrote: > > > In the suspend path, PME_Turn_Off message is sent to the endpoint to > > > transition the link to

Re: [PATCH v4 05/13] powerpc/rtas: Facilitate high-level call sequences

2023-11-30 Thread Nathan Lynch
Michael Ellerman writes: > Nathan Lynch writes: >> Michael Ellerman writes: >> >>> Nathan Lynch via B4 Relay >>> writes: From: Nathan Lynch On RTAS platforms there is a general restriction that the OS must not enter RTAS on more than one CPU at a time. This low-level

Re: [PATCH v4 05/13] powerpc/rtas: Facilitate high-level call sequences

2023-11-30 Thread Nathan Lynch
Michael Ellerman writes: > Nathan Lynch writes: >> Michael Ellerman writes: >>> Nathan Lynch writes: Michael Ellerman writes: > Nathan Lynch via B4 Relay > writes: >> From: Nathan Lynch >> >> On RTAS platforms there is a general restriction that the OS must not