* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-09 11:37 UTC (permalink / raw)
To: Michael Ellerman, Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
Vishal Verma, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Juergen Gross, Pankaj Gupta, Libor Pechacek, linux-nvdimm,
Rafael J. Wysocki, linux-kernel, Wei Yang, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <87eenbry5p.fsf@mpe.ellerman.id.au>
On 09.09.20 13:24, Michael Ellerman wrote:
> David Hildenbrand <david@redhat.com> 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 do we know what should be passed
>>> to them?
>>>
>>> Why not make this an enumerated type so that we know it all works
>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>> long feels very odd/broken...
>>
>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>> actually be passed. Thanks!
>
> You probably know this but ...
>
> Just using a C enum doesn't get you any type safety.
>
> You can get some checking via sparse by using __bitwise, which is what
> gfp_t does. You don't actually have to use an enum for that, it works
> with #defines also.
Yeah, we seem to be using different approaches. And there is always a
way to mess things up :)
gfp_t is one (extreme) example, enum memblock_flags is another example.
I tend to prefer an enum in this particular case, because it's simple
and at least tells the user which values are expected.
Thoughts?
>
> Or you can wrap the flag in a struct, the way atomic_t does, and then
> the compiler will prevent passing plain integers in place of your custom
> type.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-09-09 11:51 UTC (permalink / raw)
To: Michael Ellerman, Greg Kroah-Hartman
Cc: linux-hyperv, Michal Hocko, Michael S. Tsirkin, Jason Wang,
Pingfan Liu, virtualization, linux-mm, Paul Mackerras,
K. Y. Srinivasan, Boris Ostrovsky, linux-s390, Wei Liu,
Stefano Stabellini, Dave Jiang, Baoquan He, Jason Gunthorpe,
Vishal Verma, linux-acpi, xen-devel, Heiko Carstens, Len Brown,
Nathan Lynch, Vasily Gorbik, Leonardo Bras, Haiyang Zhang,
Stephen Hemminger, Dan Williams, Christian Borntraeger,
Juergen Gross, Pankaj Gupta, Libor Pechacek, linux-nvdimm,
Rafael J. Wysocki, linux-kernel, Wei Yang, Oliver O'Halloran,
Andrew Morton, linuxppc-dev
In-Reply-To: <5145c5c4-d9c0-85a8-7e0b-ccfa03eb0427@redhat.com>
On 09.09.20 13:37, David Hildenbrand wrote:
> On 09.09.20 13:24, Michael Ellerman wrote:
>> David Hildenbrand <david@redhat.com> 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 do we know what should be passed
>>>> to them?
>>>>
>>>> Why not make this an enumerated type so that we know it all works
>>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>>> long feels very odd/broken...
>>>
>>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>>> actually be passed. Thanks!
>>
>> You probably know this but ...
>>
>> Just using a C enum doesn't get you any type safety.
>>
>> You can get some checking via sparse by using __bitwise, which is what
>> gfp_t does. You don't actually have to use an enum for that, it works
>> with #defines also.
>
> Yeah, we seem to be using different approaches. And there is always a
> way to mess things up :)
>
> gfp_t is one (extreme) example, enum memblock_flags is another example.
> I tend to prefer an enum in this particular case, because it's simple
> and at least tells the user which values are expected.
>
Gave it another try, looks like mhp_t (like gfp_t) is actually nicer.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
From: Gerald Schaefer @ 2020-09-09 12:29 UTC (permalink / raw)
To: Dave Hansen
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
linux-sparc, Alexander Gordeev, Claudio Imbrenda, Will Deacon,
linux-arch, linux-s390, Vasily Gorbik, Christian Borntraeger,
Richard Weinberger, linux-x86, Russell King, Jason Gunthorpe,
Ingo Molnar, Catalin Marinas, Andrey Ryabinin, Heiko Carstens,
Arnd Bergmann, John Hubbard, Jeff Dike, linux-um, Borislav Petkov,
Andy Lutomirski, Thomas Gleixner, linux-arm, linux-power, LKML,
Andrew Morton, Linus Torvalds, Mike Rapoport
In-Reply-To: <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com>
On Tue, 8 Sep 2020 07:30:50 -0700
Dave Hansen <dave.hansen@intel.com> 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 it be fair to say that the "fake" page table entries s390
> allocates on the stack are what's causing the trouble here? That might
> be a nice thing to open up with here. "Dynamic page table folding"
> really means nothing to me.
Sorry, I guess my previous reply does not really explain "what the heck
is dynamic page table folding?".
On s390, we can have different number of page table levels for different
processes / mms. We always start with 3 levels, and update dynamically
on process demand to 4 or 5 levels, hence the dynamic folding. Still,
the PxD_SIZE/SHIFT is defined statically, so that e.g. pXd_addr_end() will
not reflect this dynamic behavior.
For the various pagetable walkers using pXd_addr_end() (w/o READ_ONCE
logic) this is no problem. With static folding, iteration over the folded
levels will always happen at pgd level (top-level folding). For s390,
we stay at the respective level and iterate there (dynamic middle-level
folding), only return to pgd level if there really were 5 levels.
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 local pXd values on the stack, because of
the READ_ONCE logic, and our middle-level iteration will suddenly iterate
over such stack pointers instead of pagetable pointers.
This will be addressed by making the pXd_addr_end() dynamic, for which
we need to see the pXd value in order to determine its level / type.
^ permalink raw reply
* Re: [PATCH v3] pseries/drmem: don't cache node id in drmem_lmb struct
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev
Cc: Nathan Lynch, Laurent Dufour, Michal Suchanek, Rick Lindsley,
David Hildenbrand
In-Reply-To: <20200811015115.63677-1-cheloha@linux.ibm.com>
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 memory_block. As find_memory_block() runs in sub-linear
> time this approach is negligibly slower than what we do at present.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/drmem: don't cache node id in drmem_lmb struct
https://git.kernel.org/powerpc/c/e5e179aa3a39c818db8fbc2dce8d2cd24adaf657
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/perf: consolidate GPCI hcall structs into asm/hvcall.h
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Scott Cheloha, linuxppc-dev; +Cc: Nathan Lynch, Tyrel Datwylder
In-Reply-To: <20200727184605.2945095-1-cheloha@linux.ibm.com>
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 in perf/hv-gpci.h.
Applied to powerpc/next.
[1/2] powerpc/perf: consolidate GPCI hcall structs into asm/hvcall.h
https://git.kernel.org/powerpc/c/59562b5c33d6ff3685509ed58b2ed3c5b5712704
[2/2] powerpc/pseries: new lparcfg key/value pair: partition_affinity_score
https://git.kernel.org/powerpc/c/5d1bc776428f34941a6237afb9454061b5b5e1e1
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/fpu: Drop cvt_fd() and cvt_df()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d5641ada199b8dd2af16ad00a66084cf974f2704.1596716418.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:20:34 +0000 (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()
https://git.kernel.org/powerpc/c/63442de4301188129e1fcff144fbfb966ad5eb19
[2/2] powerpc: drop hard_reset_now() and poweroff_now() declaration
https://git.kernel.org/powerpc/c/82eb1792426f8a171cdaa6cfccb63c39f55bc9bd
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/hwirq: Remove stale forward irq_chip declaration
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fbe58d27cf128d5fe581e4510ded8701858f268e.1596716328.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:19:06 +0000 (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] powerpc/hwirq: Remove stale forward irq_chip declaration
https://git.kernel.org/powerpc/c/169b9afee572853522901b7cbf34842c0494a887
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix assembler warning about r0
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2b69ac8e1cddff6f808fc7415907179eab4aae9e.1596693679.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 06:01:42 +0000 (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 content of
> r0, making the use of r0 in the source potentially confusing.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Fix assembler warning about r0
https://git.kernel.org/powerpc/c/b51ba4fe2e134b631f9c8f45423707aab71449b5
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/irq: Drop forward declaration of struct irqaction
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e0bcdabac45fcd26c02d7df273bd4a5827c6033d.1596716375.git.christophe.leroy@csgroup.eu>
On Thu, 6 Aug 2020 12:19:46 +0000 (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
https://git.kernel.org/powerpc/c/b134cfc3e3276ccd5d29e39de5c848a45b08e410
cheers
^ permalink raw reply
* Re: [PATCH v1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <9d11143d4e27ba8274369a926968756917584868.1597643153.git.christophe.leroy@csgroup.eu>
On Mon, 17 Aug 2020 05:46:39 +0000 (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 CONFIG_FUNCTION_GRAPH_TRACER
https://git.kernel.org/powerpc/c/353bce211e00d183344f464ba1ee0e1ffb0e2a6c
cheers
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc: Remove flush_instruction_cache for book3s/32
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: hch, Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <50098f49877cea0f46730a9df82dcabf84160e4b.1597384512.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 05:56:24 +0000 (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: flush_instruction_cache();
> arch/powerpc/mm/nohash/fsl_booke.c: flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c: flush_instruction_cache();
>
> [...]
Applied to powerpc/next.
[1/4] powerpc: Remove flush_instruction_cache for book3s/32
https://git.kernel.org/powerpc/c/e426ab39f41045a4c163031272b2f48d944b69c0
[2/4] powerpc: Move flush_instruction_cache() prototype in asm/cacheflush.h
https://git.kernel.org/powerpc/c/f663f3312051402d32952c44d156a20c0b854753
[3/4] powerpc: Rewrite 4xx flush_cache_instruction() in C
https://git.kernel.org/powerpc/c/de39b19452e784de5f90ae899851ab29a29bb42c
[4/4] powerpc: Rewrite FSL_BOOKE flush_cache_instruction() in C
https://git.kernel.org/powerpc/c/704dfe931df951895dea98bd1d9cacbb601b6451
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Drop _nmask_and_or_msr()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c2d2b8dfb8dd677026b26dffc8d31070c38a6b89.1597388079.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 06:54:49 +0000 (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] powerpc: Drop _nmask_and_or_msr()
https://git.kernel.org/powerpc/c/e53281bc21f061f96c9004f534bc3e807d70cb73
cheers
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c27bc4e598daf3bbb225de7a1f5c52121cf1e279.1597235091.git.christophe.leroy@csgroup.eu>
On Wed, 12 Aug 2020 12:25:16 +0000 (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 get more optimised code.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
https://git.kernel.org/powerpc/c/c20beffeec3cb6f6f52d9aef27f91a3f453a91f4
[2/2] powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()
https://git.kernel.org/powerpc/c/2f279eeb68b8eda43a95255db701b4faaeedbe0f
cheers
^ permalink raw reply
* Re: [PATCH][V2] macintosh: windfarm: remove detatch debug containing spelling mistakes
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Wolfram Sang, Colin King, Benjamin Herrenschmidt
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20200806102901.44988-1-colin.king@canonical.com>
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 spelling mistakes
https://git.kernel.org/powerpc/c/7db0a07273e8f581d0b3e8a102d3d9dd99f43528
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Remove flush_instruction_cache() on 8xx
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: hch, Michael Ellerman, Christophe Leroy, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <245cabd8f291facac8c8c5fd370e361a69e02860.1597384145.git.christophe.leroy@csgroup.eu>
On Fri, 14 Aug 2020 05:49:29 +0000 (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
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200825035147.3239-1-jniethe5@gmail.com>
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 this.
Applied to powerpc/next.
[1/1] powerpc/boot: Update Makefile comment for 64bit wrapper
https://git.kernel.org/powerpc/c/364b236a0b6e86439b9025d961da8602db23d5bf
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200824131231.14008-1-jniethe5@gmail.com>
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 will mean that the suffix is then executed which is
> incorrect. Instead check if the major opcode indicates a prefixed
> instruction (e.g. it is 1) and if so increment PT_NIP by 8.
>
> [...]
Applied to powerpc/next.
[1/1] selftests/powerpc: Fix prefixes in alignment_handler signal handler
https://git.kernel.org/powerpc/c/db96221a683342fd4775fd820a4d5376cd2f2ed0
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Update documentation of ISA versions for Power10
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe
In-Reply-To: <20200827040556.1783-1-jniethe5@gmail.com>
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
https://git.kernel.org/powerpc/c/51a1588154cb1ddc4fe8fa786324dca398f1a458
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Print helpful message when cores guarded
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman, Joel Stanley
In-Reply-To: <20190801051630.5804-1-joel@jms.id.au>
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 powerpc/next.
[1/1] powerpc/powernv: Print helpful message when cores guarded
https://git.kernel.org/powerpc/c/8f55984f530d7275531e17f36ea29229c2c410dd
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Joel Stanley; +Cc: Gautham R Shenoy, Tyrel Datwyler
In-Reply-To: <20200630015935.2675676-1-joel@jms.id.au>
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: stable@vger.kernel.org # v3.14
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> --
> v2:
> Use pr_warn instead of WARN
> Reword and print proccess name with pid in message
> Leave CPU_FTR_SMT test in
> Add Fixes line
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Warn about use of smt_snooze_delay
https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc: Warn about use of smt_snooze_delay
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: linuxppc-dev, Joel Stanley; +Cc: Gautham R . Shenoy
In-Reply-To: <20200902000012.3440389-1-joel@jms.id.au>
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 / 4 SMT system showed the warning to
> be noisy, as the online/offline loop is slow.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Warn about use of smt_snooze_delay
https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217
cheers
^ permalink raw reply
* Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Leonardo Bras, Murilo Fossa Vicentini, Michael Ellerman,
Alexey Kardashevskiy, David Dai, Ram Pai, Thiago Jung Bauermann,
Paul Mackerras, Benjamin Herrenschmidt, Brian King
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200805030455.123024-1-leobras.c@gmail.com>
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 procedure:
> 1. Remove the default DMA window,
> 2. Query for which configs the DDW can be created,
> 3. Create a DDW.
>
> [...]
Applied to powerpc/next.
[1/4] powerpc/pseries/iommu: Create defines for operations in ibm, ddw-applicable
https://git.kernel.org/powerpc/c/cac3e629086f1b2e31c87a6c9b0130d29843ae86
[2/4] powerpc/pseries/iommu: Update call to ibm, query-pe-dma-windows
https://git.kernel.org/powerpc/c/80f0251231131d164eddab78d2b6c1b8e37d0093
[3/4] powerpc/pseries/iommu: Move window-removing part of remove_ddw into remove_dma_window
https://git.kernel.org/powerpc/c/74d0b3994e147a2b503170b5e02f1d07dc086586
[4/4] powerpc/pseries/iommu: Allow bigger 64bit window by removing default DMA window
https://git.kernel.org/powerpc/c/8c0d51592f6f0123953633d1ecf21e843fce0bfd
cheers
^ permalink raw reply
* Re: [PATCH 1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200813013445.686464-1-mpe@ellerman.id.au>
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 tests when CPU 0 is offline
https://git.kernel.org/powerpc/c/c0176429b7b07893a5c1fd38baff055c919ba9e3
[2/3] selftests/powerpc: Don't use setaffinity in tm-tmspr
https://git.kernel.org/powerpc/c/769628710c33b18ede837bb488e1d24084b35592
[3/3] selftests/powerpc: Run tm-tmspr test for longer
https://git.kernel.org/powerpc/c/b5a646a681f5d67ea5190a71d6e84a91efe63b7a
cheers
^ permalink raw reply
* Re: [PATCH 1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
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
https://git.kernel.org/powerpc/c/34c103342be3f9397e656da7c5cc86e97b91f514
[2/9] selftests/powerpc: Give the bad_accesses test longer to run
https://git.kernel.org/powerpc/c/17c98a541dc9bb1162877af41cddbdca043f9a59
[3/9] selftests/powerpc: Move set_dscr() into rfi_flush.c
https://git.kernel.org/powerpc/c/d89002397cfb2b65267d6688fe671ee1cf7c5f0d
[4/9] selftests/powerpc: Include asm/cputable.h from utils.h
https://git.kernel.org/powerpc/c/178282a054dced1a08a9683d41ac08cbace2b2fe
[5/9] selftests/powerpc: Don't run DSCR tests on old systems
https://git.kernel.org/powerpc/c/4c3c3c502575556c4bc1b401235e641863b1bce6
[6/9] selftests/powerpc: Skip security tests on older CPUs
https://git.kernel.org/powerpc/c/3a31518a242dcb262b008d3bb5d4b1cf50cf4026
[7/9] selftests/powerpc: Skip L3 bank test on older CPUs
https://git.kernel.org/powerpc/c/4871a10b7b5f6b0632bff229884dad1cb1e8dc37
[8/9] selftests/powerpc: Don't touch VMX/VSX on older CPUs
https://git.kernel.org/powerpc/c/09275d717d1b2d7d5ed91f2140bb34246514a1b4
[9/9] selftests/powerpc: Properly handle failure in switch_endian_test
https://git.kernel.org/powerpc/c/003d6f5fd2cc3b529f3e6c529bc4bb0792930212
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/64: Remove unused generic_secondary_thread_init()
From: Michael Ellerman @ 2020-09-09 13:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200819015704.1976364-1-mpe@ellerman.id.au>
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 into
> generic_secondary_thread_init(). So we can remove the _GLOBAL but not
> the body of the function.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64: Remove unused generic_secondary_thread_init()
https://git.kernel.org/powerpc/c/529d2bd56ada4b8a4904909042792879868208cd
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox