On 7/22/21 8:06 AM, David Gibson wrote:
On Thu, Jul 22, 2021 at 11:59:15AM +1000, David Gibson wrote:
On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
No functional change in this patch.
The new name does not match how you describe "primary domain index" in
the documentation
randconfig-a016-20210721
i386 randconfig-a013-20210721
i386 randconfig-a012-20210721
i386 randconfig-a014-20210721
i386 randconfig-a011-20210721
i386 randconfig-a015-20210721
riscvnommu_k210_defconfig
riscv
On Thu, Jul 22, 2021 at 11:59:15AM +1000, David Gibson wrote:
> On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
> > No functional change in this patch.
>
> The new name does not match how you describe "primary domain index" in
> the documentation from patch 6/6. There it comes
On Mon, Jun 28, 2021 at 08:41:13PM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch
>
> Signed-off-by: Aneesh Kumar K.V
Reviewed-by: David Gibson
> ---
> arch/powerpc/mm/numa.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git
On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch.
The new name does not match how you describe "primary domain index" in
the documentation from patch 6/6. There it comes from the values in
associativity-reference-points, but here it simply
On Mon, Jun 28, 2021 at 08:41:15PM +0530, Aneesh Kumar K.V wrote:
> The associativity details of the newly added resourced are collected from
> the hypervisor via "ibm,configure-connector" rtas call. Update the numa
> distance details of the newly added numa node after the above call.
>
> Instead
On Mon, Jun 28, 2021 at 08:41:16PM +0530, Aneesh Kumar K.V wrote:
> This helper is only used with the dispatch trace log collection.
> A later patch will add Form2 affinity support and this change helps
> in keeping that simpler. Also add a comment explaining we don't expect
> the code to be
On Mon, Jun 28, 2021 at 08:41:17PM +0530, Aneesh Kumar K.V wrote:
> PAPR interface currently supports two different ways of communicating resource
> grouping details to the OS. These are referred to as Form 0 and Form 1
> associativity grouping. Form 0 is the older format and is now considered
>
On Thu, Jul 22, 2021 at 10:59:09AM +1000, David Gibson wrote:
> On Mon, Jun 28, 2021 at 08:41:13PM +0530, Aneesh Kumar K.V wrote:
> > No functional change in this patch
> >
> > Signed-off-by: Aneesh Kumar K.V
>
> Reviewed-by: David Gibson
No... wait, I take that back. This change makes the
randconfig-a012-20210720
i386 randconfig-a014-20210720
i386 randconfig-a011-20210720
i386 randconfig-a015-20210720
i386 randconfig-a016-20210721
i386 randconfig-a013-20210721
i386
On Wed 2021-07-21 14:52:15, John Ogness wrote:
> On 2021-07-21, Petr Mladek wrote:
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mode
> >> oops_dump_mode)
> >>tracing_off();
> >>
> >>local_irq_save(flags);
>
On Thu 2021-07-15 21:39:57, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
>
> There are several parts of the kernel that are
On Thu 2021-07-15 21:39:56, John Ogness wrote:
> With @logbuf_lock removed, the high level printk functions for
> storing messages are lockless. Messages can be stored from any
> context, so there is no need for the NMI and safe buffers anymore.
> Remove the NMI and safe buffers.
>
> Although the
On 21/07/2021 05:32, Alexey Kardashevskiy wrote:
+ struct iommu_table *newtbl;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(pci->phb->mem_resources); i++) {
+ const unsigned long mask = IORESOURCE_MEM_64 |
IORESOURCE_MEM;
+
+ /* Look for MMIO32 */
+
On 2021-07-21, Petr Mladek wrote:
> On Wed 2021-07-21 14:52:15, John Ogness wrote:
>> On 2021-07-21, Petr Mladek wrote:
>> >> --- a/kernel/trace/trace.c
>> >> +++ b/kernel/trace/trace.c
>> >> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mode
>> >> oops_dump_mode)
>> >>
On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this is v4 of the final patch set for my effort to make struct
> bus_type::remove return void.
>
> The first four patches contain cleanups that make some of these
> callbacks (more obviously) always return 0. They are
On 2021-07-21, Petr Mladek wrote:
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mode oops_dump_mode)
>> tracing_off();
>>
>> local_irq_save(flags);
>> -printk_nmi_direct_enter();
>> +
On Wed, 21 Jul 2021 17:02:13 +1000, Michael Ellerman wrote:
> This reverts commit c742199a014de23ee92055c2473d91fe5561ffdf.
>
> c742199a014d ("mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge")
> breaks arm64 in at least two ways for configurations where PUD or PMD
> folding occur:
>
> 1.
Am 21.07.21 um 08:51 schrieb Christoph Hellwig:
On Wed, Jul 21, 2021 at 08:29:43AM +0200, Christian K??nig wrote:
Looks good in general, but question is what about other architectures like
ARM?
DRM_AMD_DC_DCN currently requires X86 || PPC64.
And exactly that's the problem I'm noting here. At
On Fri, 16 Jul 2021 12:43:09 +1000, Nicholas Piggin wrote:
> When running CPU_FTR_P9_TM_HV_ASSIST, HFSCR[TM] is set for the guest
> even if the host has CONFIG_TRANSACTIONAL_MEM=n, which causes it to be
> unprepared to handle guest exits while transactional.
>
> Normal guests don't have a problem
From: Jonathan Marek
This reverts commit c742199a014de23ee92055c2473d91fe5561ffdf.
c742199a014d ("mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge")
breaks arm64 in at least two ways for configurations where PUD or PMD
folding occur:
1. We no longer install huge-vmap mappings and
> +
> +/*
> + * Use kernel_fpu_begin/end() if you intend to use FPU in kernel context. It
> + * disables preemption so be careful if you intend to use it for long periods
> + * of time.
> + * TODO: If you intend to use the FPU in irq/softirq you need to check first
> with
> + * irq_fpu_usable()
On Wed, Jul 21, 2021 at 08:29:43AM +0200, Christian K??nig wrote:
> Looks good in general, but question is what about other architectures like
> ARM?
DRM_AMD_DC_DCN currently requires X86 || PPC64.
Maybe a good think would be to add a new KERNEL_FPU_API Kconfig symbol,
selected by x86 and
Am 21.07.21 um 06:48 schrieb Anson Jacob:
Use kernel_fpu_begin & kernel_fpu_end for PPC
Depends on "ppc/fpu: Add generic FPU api similar to x86"
v2:
- Got rid of macro switch for PPC as header file with same
name as x86 is added by previous patch in the series
Signed-off-by: Anson Jacob
24 matches
Mail list logo
