Re: [PATCH kernel] powerpc/dma: Fix dma_map_ops::get_required_mask

2020-09-09 Thread Alexey Kardashevskiy
On 09/09/2020 17:58, Christoph Hellwig wrote: > On Tue, Sep 08, 2020 at 11:10:03PM +1000, Alexey Kardashevskiy wrote: a-ha, this makes more sense, thanks. Then I guess we need to revert that one bit from yours f1565c24b596, do not we? >>> >>> Why? The was the original intent of the

Re: [PATCH v3] pseries/drmem: don't cache node id in drmem_lmb struct

2020-09-09 Thread Michael Ellerman
On Mon, 10 Aug 2020 20:51:15 -0500, Scott Cheloha wrote: > At memory hot-remove time we can retrieve an LMB's nid from its > corresponding memory_block. There is no need to store the nid > in multiple locations. > > Note that lmb_to_memblock() uses find_memory_block() to get the > corresponding

Re: [PATCH] powerpc/irq: Drop forward declaration of struct irqaction

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 12:19:46 + (UTC), Christophe Leroy wrote: > Since the commit identified below, the forward declaration of > struct irqaction is useless. Drop it. Applied to powerpc/next. [1/1] powerpc/irq: Drop forward declaration of struct irqaction

Re: [PATCH][V2] macintosh: windfarm: remove detatch debug containing spelling mistakes

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 11:29:01 +0100, Colin King wrote: > There are spelling mistakes in two debug messages. As recommended > by Wolfram Sang, these can be removed as there is plenty of debug > in the driver core. Applied to powerpc/next. [1/1] macintosh: windfarm: remove detatch debug containing

Re: [PATCH] powerpc/32s: Fix assembler warning about r0

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 06:01:42 + (UTC), Christophe Leroy wrote: > The assembler says: > arch/powerpc/kernel/head_32.S:1095: Warning: invalid register expression > > It's objecting to the use of r0 as the RA argument. That's because > when RA = 0 the literal value 0 is used, rather than the

Re: [PATCH] powerpc/powernv: Print helpful message when cores guarded

2020-09-09 Thread Michael Ellerman
On Thu, 1 Aug 2019 14:46:30 +0930, Joel Stanley wrote: > Often the firmware will guard out cores after a crash. This often > undesirable, and is not immediately noticeable. > > This adds an informative message when a CPU device tree nodes are marked > bad in the device tree. Applied to

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Gerald Schaefer
On Wed, 9 Sep 2020 13:38:25 +0530 Anshuman Khandual wrote: > > > On 09/04/2020 08:56 PM, Gerald Schaefer wrote: > > On Fri, 4 Sep 2020 12:18:05 +0530 > > Anshuman Khandual wrote: > > > >> > >> > >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: > >>> This patch series includes fixes for

Re: [PATCH 1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 12:20:34 + (UTC), Christophe Leroy wrote: > Those two functions have been unused since commit identified below. > Drop them. Applied to powerpc/next. [1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()

Re: [PATCH v2] powerpc: Update documentation of ISA versions for Power10

2020-09-09 Thread Michael Ellerman
On Thu, 27 Aug 2020 14:05:56 +1000, Jordan Niethe wrote: > Update the CPU to ISA Version Mapping document to include Power10 and > ISA v3.1. Applied to powerpc/next. [1/1] powerpc: Update documentation of ISA versions for Power10

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-09 Thread Michael Ellerman
David Hildenbrand writes: > On 09.09.20 09:17, Greg Kroah-Hartman wrote: >> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: >>> We soon want to pass flags, e.g., to mark added System RAM resources. >>> mergeable. Prepare for that. >> >> What are these random "flags", and how

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-09 Thread David Hildenbrand
On 09.09.20 13:24, Michael Ellerman wrote: > David Hildenbrand writes: >> On 09.09.20 09:17, Greg Kroah-Hartman wrote: >>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for

Re: [PATCH v2 1/2] powerpc/perf: consolidate GPCI hcall structs into asm/hvcall.h

2020-09-09 Thread Michael Ellerman
On Mon, 27 Jul 2020 13:46:04 -0500, Scott Cheloha wrote: > The H_GetPerformanceCounterInfo (GPCI) hypercall input/output structs are > useful to modules outside of perf/, so move them into asm/hvcall.h to live > alongside the other powerpc hypercall structs. > > Leave the perf-specific GPCI stuff

Re: [PATCH v2 1/4] powerpc: Remove flush_instruction_cache for book3s/32

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 05:56:24 + (UTC), Christophe Leroy wrote: > The only callers of flush_instruction_cache() are: > > arch/powerpc/kernel/swsusp_booke.S: bl flush_instruction_cache > arch/powerpc/mm/nohash/40x.c: flush_instruction_cache(); > arch/powerpc/mm/nohash/44x.c:

Re: Flushing transparent hugepages

2020-09-09 Thread Aneesh Kumar K.V
Matthew Wilcox writes: > PowerPC has special handling of hugetlbfs pages. Well, that's what > the config option says, but actually it handles THP as well. If > the config option is enabled. > > #ifdef CONFIG_HUGETLB_PAGE > if (PageCompound(page)) { >

Re: [PATCH v2] powerpc: Remove flush_instruction_cache() on 8xx

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 05:49:29 + (UTC), Christophe Leroy wrote: > flush_instruction_cache() is never used on 8xx, remove it. Applied to powerpc/next. [1/1] powerpc: Remove flush_instruction_cache() on 8xx https://git.kernel.org/powerpc/c/76d46a1e2fe2c35f24c07b7cc8a41afbf98b349e cheers

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Gerald Schaefer
On Tue, 8 Sep 2020 07:30:50 -0700 Dave Hansen wrote: > On 9/7/20 11:00 AM, Gerald Schaefer wrote: > > Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast > > code") introduced a subtle but severe bug on s390 with gup_fast, due to > > dynamic page table folding. > > Would

Re: [PATCH v1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER

2020-09-09 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:39 + (UTC), Christophe Leroy wrote: > ftrace_graph_ret_addr() is always defined and returns 'ip' when > CONFIG_FUNCTION GRAPH_TRACER is not set. > > So the #ifdef is not needed, remove it. Applied to powerpc/next. [1/1] powerpc/process: Remove unnecessary #ifdef

Re: [PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper

2020-09-09 Thread Michael Ellerman
On Tue, 25 Aug 2020 13:51:47 +1000, Jordan Niethe wrote: > As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little > endian wrapper") the comment in the Makefile is misleading. The wrapper > packaging 64bit kernel may built as a 32 or 64 bit elf. Update the > comment to reflect

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Gerald Schaefer
On Wed, 09 Sep 2020 11:38:39 +0530 "Aneesh Kumar K.V" wrote: > Gerald Schaefer writes: > > > On Fri, 4 Sep 2020 18:01:15 +0200 > > Gerald Schaefer wrote: > > > > [...] > >> > >> BTW2, a quick test with this change (so far) made the issues on s390 > >> go away: > >> > >> @@ -1069,7 +1074,7

Re: [PATCH v3 1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 12:25:16 + (UTC), Christophe Leroy wrote: > At the time being, __put_user()/__get_user() and friends only use > D-form addressing, with 0 offset. Ex: > > lwz reg1, 0(reg2) > > Give the compiler the opportunity to use other adressing modes > whenever possible, to

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-09 Thread David Hildenbrand
On 09.09.20 13:37, David Hildenbrand wrote: > On 09.09.20 13:24, Michael Ellerman wrote: >> David Hildenbrand writes: >>> On 09.09.20 09:17, Greg Kroah-Hartman wrote: On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added

Re: [PATCH] powerpc/hwirq: Remove stale forward irq_chip declaration

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 12:19:06 + (UTC), Christophe Leroy wrote: > Since commit identified below, the forward declaration of > struct irq_chip is useless (was struct hw_interrupt_type at that time) > > Remove it, together with the associated comment. Applied to powerpc/next. [1/1]

Re: [PATCH v2] powerpc: Drop _nmask_and_or_msr()

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 06:54:49 + (UTC), Christophe Leroy wrote: > _nmask_and_or_msr() is only used at two places to set MSR_IP. > > The SYNC is unnecessary as the users are not PowerPC 601. > > Can be easily writen in C. > > Do it, and drop _nmask_and_or_msr() Applied to powerpc/next. [1/1]

Re: [PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler

2020-09-09 Thread Michael Ellerman
On Mon, 24 Aug 2020 23:12:31 +1000, Jordan Niethe wrote: > The signal handler in the alignment handler self test has the ability to > jump over the instruction that triggered the signal. It does this by > incrementing the PT_NIP in the user context by 4. If it were a prefixed > instruction this

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Gerald Schaefer
On Wed, 9 Sep 2020 13:45:48 +0530 Anshuman Khandual wrote: [...] > > > > That would more match the "pte_t pointer" usage for hugetlb code, > > i.e. just cast a pmd_t pointer to it. Also changed to pmd_aligned, > > but I think the root cause is the pte_t pointer. > > Ideally, the pte_t pointer

Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay

2020-09-09 Thread Michael Ellerman
On Tue, 30 Jun 2020 11:29:35 +0930, Joel Stanley wrote: > It's not done anything for a long time. Save the percpu variable, and > emit a warning to remind users to not expect it to do anything. > > Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.") > Cc:

Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window

2020-09-09 Thread Michael Ellerman
On Wed, 5 Aug 2020 00:04:51 -0300, Leonardo Bras wrote: > There are some devices in which a hypervisor may only allow 1 DMA window > to exist at a time, and in those cases, a DDW is never created to them, > since the default DMA window keeps using this resource. > > LoPAR recommends this

Re: [PATCH] powerpc/64: Remove unused generic_secondary_thread_init()

2020-09-09 Thread Michael Ellerman
On Wed, 19 Aug 2020 11:57:04 +1000, Michael Ellerman wrote: > The last caller was removed in 2014 in commit fb5a515704d7 ("powerpc: > Remove platforms/wsp and associated pieces"). > > As Jordan noticed even though there are no callers, the code above in > fsl_secondary_thread_init() falls through

Re: [PATCH] powerpc/64s: handle ISA v3.1 local copy-paste context switches

2020-09-09 Thread Michael Ellerman
On Tue, 25 Aug 2020 17:55:35 +1000, Nicholas Piggin wrote: > The ISA v3.1 the copy-paste facility has a new memory move functionality > which allows the copy buffer to be pasted to domestic memory (RAM) as > opposed to foreign memory (accelerator). > > This means the POWER9 trick of avoiding the

Re: [PATCH 0/5] powerpc: Remove five unused variables

2020-09-09 Thread Michael Ellerman
On Tue, 19 Nov 2019 14:14:29 +0800, zhengbin wrote: > zhengbin (5): > powerpc/fadump: Remove set but not used variable 'elf' > powerpc/perf: Remove set but not used variable 'target' > powerpc/powernv: Remove set but not used variable 'total_vfs' > powerpc/powernv: Remove set but not used

Re: [PATCH v2 0/4] ocxl: Cleanup AFU interrupt allocation

2020-09-09 Thread Michael Ellerman
On Fri, 3 Apr 2020 17:38:34 +0200, Frederic Barrat wrote: > Short series to cleanup AFU interrupt allocation for opencapi. > Current code was using its own allocation service, calling opal > directly to get the trigger page. This is not needed and we can use > xive to achieve the same thing. The

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Dave Hansen
On 9/9/20 5:29 AM, Gerald Schaefer wrote: > This only works well as long there are real pagetable pointers involved, > that can also be used for iteration. For gup_fast, or any other future > pagetable walkers using the READ_ONCE logic w/o lock, that is not true. > There are pointers involved to

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-09 Thread Linus Torvalds
On Thu, Sep 3, 2020 at 7:28 AM Al Viro wrote: > > I can live with this series; do you want that in vfs.git#for-next? Well, it's apparently there now (at least it's in your base.set_fs branch, I didn't check actual -next). So this is just a heads-up that I plan to merge the "asm goto" changes on

Re: [PATCH v3] powerpc: Warn about use of smt_snooze_delay

2020-09-09 Thread Michael Ellerman
On Wed, 2 Sep 2020 09:30:11 +0930, Joel Stanley wrote: > It's not done anything for a long time. Save the percpu variable, and > emit a warning to remind users to not expect it to do anything. > > This uses pr_warn_once instead of pr_warn_ratelimit as testing > 'ppc64_cpu --smt=off' on a 24 core

Re: [PATCH] powerpc/tools: Remove 90 line limit in checkpatch script

2020-09-09 Thread Michael Ellerman
On Fri, 28 Aug 2020 12:05:42 +1000, Russell Currey wrote: > As of commit bdc48fa11e46, scripts/checkpatch.pl now has a default line > length warning of 100 characters. The powerpc wrapper script was using > a length of 90 instead of 80 in order to make checkpatch less > restrictive, but now it's

Re: [PATCH 0/2] powerpc: unrel_branch_check.sh: enable llvm-objdump

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 18:10:34 +1000, Stephen Rothwell wrote: > These 2 patches enable this script to work properly when llvm-objtool > is being used. > > They depend on my previos series that make this script suck less. Applied to powerpc/next. [1/2] powerpc: unrel_branch_check.sh: use nm to

Re: [PATCH] powerpc: hwrng; fix missing of_node_put()

2020-09-09 Thread Michael Ellerman
On Mon, 2 Jul 2018 11:08:16 +0200, Nicholas Mc Guire wrote: > The call to of_find_compatible_node() returns a node pointer with refcount > incremented thus it must be explicitly decremented here before returning. Applied to powerpc/next. [1/1] powerpc/pseries: Fix missing of_node_put() in

Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Gerald Schaefer
On Tue, 8 Sep 2020 19:36:50 +0200 Gerald Schaefer wrote: [..] > > It seems now that the generalization is very well accepted so far, > apart from some apparent issues on arm. Also, merging 2 + 3 and > putting them first seems to be acceptable, so we could do that for > v3, if there are no

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Gerald Schaefer
On Wed, 9 Sep 2020 09:18:46 -0700 Dave Hansen wrote: > On 9/9/20 5:29 AM, Gerald Schaefer wrote: > > This only works well as long there are real pagetable pointers involved, > > that can also be used for iteration. For gup_fast, or any other future > > pagetable walkers using the READ_ONCE logic

Re: [PATCH 1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac

2020-09-09 Thread Michael Ellerman
On Wed, 19 Aug 2020 11:57:19 +1000, Michael Ellerman wrote: > These platforms don't show the MMU in /proc/cpuinfo, but they always > use hash, so teach using_hash_mmu() that. Applied to powerpc/next. [1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac

Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Tue, 28 Jul 2020 12:37:41 -0500, Nathan Lynch wrote: > The drmem lmb list can have hundreds of thousands of entries, and > unfortunately lookups take the form of linear searches. As long as > this is the case, traversals have the potential to monopolize the CPU > and provoke lockup reports,

Re: [PATCH] powerpc/pseries/eeh: Fix dumb linebreaks

2020-09-09 Thread Michael Ellerman
On Tue, 18 Aug 2020 14:45:57 +1000, Oliver O'Halloran wrote: > These annoy me every time I see them. Why are they here? They're not even > needed for 80cols compliance. Applied to powerpc/next. [1/1] powerpc/pseries/eeh: Fix dumb linebreaks

Re: [v3 1/2] dts: ppc: t4240rdb: remove interrupts property

2020-09-09 Thread Michael Ellerman
On Wed, 27 May 2020 11:42:27 +0800, Biwen Li wrote: > Since the interrupt pin for RTC DS1374 is not connected > to the CPU on T4240RDB, remove the interrupt property > from the device tree. > > This also fix the following warning for hwclock.util-linux: > $ hwclock.util-linux >

Re: [PATCH] powerpc: icp-hv: fix missing of_node_put in success path

2020-09-09 Thread Michael Ellerman
On Wed, 4 Jul 2018 10:03:27 +0200, Nicholas Mc Guire wrote: > Both of_find_compatible_node() and of_find_node_by_type() will > return a refcounted node on success - thus for the success path > the node must be explicitly released with a of_node_put(). Applied to powerpc/next. [1/1]

Re: [PATCH 1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 11:34:43 +1000, Michael Ellerman wrote: > Several of the TM tests fail spuriously if CPU 0 is offline, because > they blindly try to affinitise to CPU 0. > > Fix them by picking any online CPU and using that instead. Applied to powerpc/next. [1/3] selftests/powerpc: Fix TM

Re: [PATCH 0/7] powerpc: unrel_branch_check.sh: make it suck less

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 00:04:27 +1000, Stephen Rothwell wrote: > Michael Ellerman: "who wants to make > arch/powerpc/tools/unrel_branch_check.sh suck less" > > This series is based off the current powerpc/next branch and keeps the > same functionaity as the original except that it suppresses some

Re: [PATCH] arch/powerpc: use simple i2c probe function

2020-09-09 Thread Michael Ellerman
On Fri, 7 Aug 2020 17:27:13 +0200, Stephen Kitt wrote: > The i2c probe functions here don't use the id information provided in > their second argument, so the single-parameter i2c probe function > ("probe_new") can be used instead. > > This avoids scanning the identifier tables during probes.

Re: [PATCH] powerpc/oprofile: fix spelling mistake "contex" -> "context"

2020-09-09 Thread Michael Ellerman
On Tue, 4 Aug 2020 18:43:16 +0100, Colin King wrote: > There is a spelling mistake in a pr_debug message. Fix it. Applied to powerpc/next. [1/1] powerpc/oprofile: fix spelling mistake "contex" -> "context" https://git.kernel.org/powerpc/c/346427e668163e85cbbe14e4d9a2ddd49df1536c cheers

Re: [PATCH 1/6] powerpc/powernv/smp: Fix spurious DBG() warning

2020-09-09 Thread Michael Ellerman
On Tue, 4 Aug 2020 10:54:05 +1000, Oliver O'Halloran wrote: > When building with W=1 we get the following warning: > > arch/powerpc/platforms/powernv/smp.c: In function > ‘pnv_smp_cpu_kill_self’: > arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around > empty body

Re: [PATCH] cxl: Rework error message for incompatible slots

2020-09-09 Thread Michael Ellerman
On Tue, 7 Apr 2020 13:56:01 +0200, Frederic Barrat wrote: > Improve the error message shown if a capi adapter is plugged on a > capi-incompatible slot directly under the PHB (no intermediate switch). Applied to powerpc/next. [1/1] cxl: Rework error message for incompatible slots

Re: [PATCH v3] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote: > The drmem lmb list can have hundreds of thousands of entries, and > unfortunately lookups take the form of linear searches. As long as > this is the case, traversals have the potential to monopolize the CPU > and provoke lockup reports,

Re: [PATCH v3] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote: > The drmem lmb list can have hundreds of thousands of entries, and > unfortunately lookups take the form of linear searches. As long as > this is the case, traversals have the potential to monopolize the CPU > and provoke lockup reports,

Re: [PATCH 1/2] powerpc/vmemmap: Fix memory leak with vmemmap list allocation failures.

2020-09-09 Thread Michael Ellerman
On Fri, 31 Jul 2020 17:04:59 +0530, Aneesh Kumar K.V wrote: > If we fail to allocate vmemmap list, we don't keep track of allocated > vmemmap block buf. Hence on section deactivate we skip vmemmap block > buf free. This results in memory leak. Applied to powerpc/next. [1/2] powerpc/vmemmap: Fix

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-09 Thread Linus Torvalds
On Wed, Sep 9, 2020 at 11:42 AM Segher Boessenkool wrote: > > It will not work like this in GCC, no. The LLVM people know about that. > I do not know why they insist on pushing this, being incompatible and > everything. Umm. Since they'd be the ones supporting this, *gcc* would be the

Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3

2020-09-09 Thread Segher Boessenkool
On Wed, Sep 09, 2020 at 10:31:34AM -0700, Linus Torvalds wrote: > And apparently there are people working on this on the gcc side too, > so it won't just be clang-specific. Nor kernel-specific in that Nick > tells me some other projects are looking at using that asm goto with > outputs too. It

[trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Joe Perches
fallthrough to a separate case/default label break; isn't very readable. Convert pseudo-keyword fallthrough; statements to a simple break; when the next label is case or default and the only statement in the next label block is break; Found using: $ grep-2.5.4 -rP --include=*.[ch] -n

Re: [PATCH] scsi: ibmvfc: Fix error return in ibmvfc_probe()

2020-09-09 Thread Tyrel Datwyler
On 9/7/20 1:39 AM, Jing Xiangfeng wrote: > Fix to return error code PTR_ERR() from the error handling case instead > of 0. > > Signed-off-by: Jing Xiangfeng Acked-by: Tyrel Datwyler > --- > drivers/scsi/ibmvscsi/ibmvfc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Gustavo A. R. Silva
On 9/9/20 15:06, Joe Perches wrote: > fallthrough to a separate case/default label break; isn't very readable. > > Convert pseudo-keyword fallthrough; statements to a simple break; when > the next label is case or default and the only statement in the next > label block is break; > > Found

Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

2020-09-09 Thread Jason Gunthorpe
On Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote: > I actually had to draw myself a picture to get some hold of > this, or rather a walk-through with a certain pud-crossing > range in a folded 3-level scenario. Not sure if I would have > understood my explanation above w/o that, but

[powerpc:merge] BUILD SUCCESS 4b552a4cbf286ff9dcdab19153f3c1c7d1680fab

2020-09-09 Thread kernel test robot
-20200909 x86_64 randconfig-a006-20200909 x86_64 randconfig-a003-20200909 x86_64 randconfig-a001-20200909 x86_64 randconfig-a005-20200909 x86_64 randconfig-a002-20200909 i386 randconfig-a004-20200909 i386

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Jason Gunthorpe
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > fallthrough to a separate case/default label break; isn't very readable. > > Convert pseudo-keyword fallthrough; statements to a simple break; when > the next label is case or default and the only statement in the next > label block

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Joe Perches
On Wed, 2020-09-09 at 19:36 -0300, Jason Gunthorpe wrote: > On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > > fallthrough to a separate case/default label break; isn't very readable. > > > > Convert pseudo-keyword fallthrough; statements to a simple break; when > > the next label

[PATCH 1/9] powerpc/eeh: Rework EEH initialisation

2020-09-09 Thread Oliver O'Halloran
Drop the EEH register / unregister ops thing and have the platform pass the ops structure into eeh_init() directly. This takes one initcall out of the EEH setup path and it means we're only doing EEH setup on the platforms which actually support it. It's also less code and generally easier to

[PATCH 2/9] powerpc/powernv: Stop using eeh_ops->init()

2020-09-09 Thread Oliver O'Halloran
Fold pnv_eeh_init() into eeh_powernv_init() rather than having eeh_init() call it via eeh_ops->init(). It's simpler and it'll let us delete eeh_ops.init. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/eeh-powernv.c | 94 ++-- 1 file changed, 45

Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-09 Thread Keith Busch
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote: > diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c > index eea0f453cfb6..8aac5bc60f4c 100644 > --- a/crypto/tcrypt.c > +++ b/crypto/tcrypt.c > @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 mask, > int m, u32

[powerpc:fixes-test] BUILD SUCCESS 0460534b532e5518c657c7d6492b9337d975eaa3

2020-09-09 Thread kernel test robot
powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20200909 x86_64 randconfig-a006-20200909 x86_64

Re: [PATCH] scsi: ibmvfc: Fix error return in ibmvfc_probe()

2020-09-09 Thread Martin K. Petersen
Jing, > Fix to return error code PTR_ERR() from the error handling case instead > of 0. Applied to 5.10/scsi-staging. Thanks! -- Martin K. Petersen Oracle Linux Engineering

EEH cleanups and reworks

2020-09-09 Thread Oliver O'Halloran
This is really two series joined together since they end up conflicting with each other lighty slightly and I figured this is easier for all involved. Patches 1-5 streamline how the generic and platform specfic parts of EEH are initialised at boot so more of the setup process happens in linear

[powerpc:next-test] BUILD SUCCESS a24f73a061494d718b254ec7814cd10010ac2ec3

2020-09-09 Thread kernel test robot
defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20200909 x86_64 randconfig-a006-20200909 x86_64 randconfig

[PATCH 6/9] powerpc/pseries/eeh: Clean up pe_config_addr lookups

2020-09-09 Thread Oliver O'Halloran
De-duplicate, and fix up the comments, and make the prototype just take a pci_dn since the job of the function is to return the pe_config_addr of the PE which contains a given device. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/pseries/eeh_pseries.c | 80 +++- 1

[PATCH 7/9] powerpc/pseries/eeh: Rework device EEH PE determination

2020-09-09 Thread Oliver O'Halloran
The process Linux uses for determining if a device supports EEH or not appears to be at odds with what PAPR+ says the OS should be doing. The current flow is something like: 1. Assume pe_config_addr is equal the the device's config_addr. 2. Attempt to enable EEH on that PE 3. Verify EEH was

[PATCH 3/9] powerpc/pseries: Stop using eeh_ops->init()

2020-09-09 Thread Oliver O'Halloran
Fold pseries_eeh_init() into eeh_pseries_init() rather than having eeh_init() call it via eeh_ops->init(). It's simpler and it'll let us delete eeh_ops.init. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/pseries/eeh_pseries.c | 155 +-- 1 file changed, 71

[PATCH 4/9] powerpc/eeh: Delete eeh_ops->init

2020-09-09 Thread Oliver O'Halloran
No longer used since the platforms perform their EEH initialisation before calling eeh_init(). Signed-off-by: Oliver O'Halloran --- arch/powerpc/include/asm/eeh.h | 1 - arch/powerpc/kernel/eeh.c | 8 2 files changed, 9 deletions(-) diff --git a/arch/powerpc/include/asm/eeh.h

[PATCH 5/9] powerpc/eeh: Move EEH initialisation to an arch initcall

2020-09-09 Thread Oliver O'Halloran
The initialisation of EEH mostly happens in a core_initcall_sync initcall, followed by registering a bus notifier later on in an arch_initcall. Anything involving initcall dependecies is mostly incomprehensible unless you've spent a while staring at code so here's the full sequence:

Re: [PATCH v1 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification

2020-09-09 Thread Aneesh Kumar K.V
Christophe Leroy writes: > search_exception_tables() is an heavy operation, we have to avoid it. > When KUAP is selected, we'll know the fault has been blocked by KUAP. > Otherwise, it behaves just as if the address was already in the TLBs > and no fault was generated. > > Signed-off-by:

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Aneesh Kumar K.V
Gerald Schaefer writes: > On Fri, 4 Sep 2020 18:01:15 +0200 > Gerald Schaefer wrote: > > [...] >> >> BTW2, a quick test with this change (so far) made the issues on s390 >> go away: >> >> @@ -1069,7 +1074,7 @@ static int __init debug_vm_pgtable(void) >> spin_unlock(ptl); >> >>

Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

2020-09-09 Thread Alexey Kardashevskiy
On 07/08/2020 20:18, Cédric Le Goater wrote: > When a passthrough IO adapter is removed from a pseries machine using > hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the > guest OS to clear all page table entries related to the adapter. If > some are still present, the RTAS

Re: [PATCH v1 4/5] powerpc/fault: Avoid heavy search_exception_tables() verification

2020-09-09 Thread Christophe Leroy
Le 09/09/2020 à 08:04, Aneesh Kumar K.V a écrit : Christophe Leroy writes: search_exception_tables() is an heavy operation, we have to avoid it. When KUAP is selected, we'll know the fault has been blocked by KUAP. Otherwise, it behaves just as if the address was already in the TLBs and no

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-09 Thread Greg Kroah-Hartman
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that

Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends

2020-09-09 Thread David Hildenbrand
On 09.09.20 09:17, Greg Kroah-Hartman wrote: > On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: >> We soon want to pass flags, e.g., to mark added System RAM resources. >> mergeable. Prepare for that. > > What are these random "flags", and how do we know what should be passed >

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Anshuman Khandual
On 09/04/2020 08:56 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 12:18:05 +0530 > Anshuman Khandual wrote: > >> >> >> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: >>> This patch series includes fixes for debug_vm_pgtable test code so that >>> they follow page table updates rules

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Anshuman Khandual
On 09/04/2020 09:31 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 17:26:47 +0200 > Gerald Schaefer wrote: > >> On Fri, 4 Sep 2020 12:18:05 +0530 >> Anshuman Khandual wrote: >> >>> >>> >>> On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote: This patch series includes fixes for

Re: [RFC PATCH v2 2/3] mm: make pXd_addr_end() functions page-table entry aware

2020-09-09 Thread Christophe Leroy
On Tue, 2020-09-08 at 16:15 +0200, Alexander Gordeev wrote: > On Tue, Sep 08, 2020 at 10:16:49AM +0200, Christophe Leroy wrote: > > >Yes, and also two more sources :/ > > > arch/powerpc/mm/kasan/8xx.c > > > arch/powerpc/mm/kasan/kasan_init_32.c > > > > > >But these two are not quite obvious

Re: [PATCH v4 00/13] mm/debug_vm_pgtable fixes

2020-09-09 Thread Anshuman Khandual
On 09/04/2020 11:23 PM, Gerald Schaefer wrote: > On Fri, 4 Sep 2020 18:01:15 +0200 > Gerald Schaefer wrote: > >> On Fri, 4 Sep 2020 17:26:47 +0200 >> Gerald Schaefer wrote: >> >>> On Fri, 4 Sep 2020 12:18:05 +0530 >>> Anshuman Khandual wrote: >>> On 09/02/2020 05:12 PM, Aneesh