Re:[PATCH 00/13] Modernize Loongson64 Machine

Hi, Jiaxun, 1, To describe CPU I prefer "loongson" to "ls" because "ls" is confusing, and in future we will use ls2h/ls7a to describe Loongson's bridge. 2, I think it is better to use loongson64c/loongson64g than loongson2ef/loongson64. As we disscussed, we will use

Re:Re：Re: Re：[PATCH 4.9 81/96] MIPS:Loongson: Introduce and use loongson_llsc_mb()

Hi, Greg, Patch for 4.9 (and below 4.9) is here: https://patchwork.linux-mips.org/patch/21375/ Huacai -- Original -- From: "陈华才"; Date: Thu, Mar 14, 2019 06:55 AM To: "gregkh"; Cc: "linux-kernel"; "stable"; &

Re: [PATCH V3 1/5] genirq/affinity: don't mark 'affd' as const

vectors) is correct. There may be similar problems except nvme. Huacai -- Original -- From: "Thomas Gleixner"; Date: Thu, Feb 14, 2019 09:31 PM To: "陈华才"; Cc: "Keith Busch"; "Bjorn Helgaas"; "Jens Axboe"; &

Re: [PATCH V3 1/5] genirq/affinity: don't mark 'affd' as const

I'll test next week, but 4.19 has the same problem, how to fix that for 4.19? Huacai -- Original -- From: "Thomas Gleixner"; Date: Thu, Feb 14, 2019 04:50 PM To: "Keith Busch"; Cc: "Bjorn Helgaas"; "Jens Axboe"; "Sagi Grimberg"; "linux-pci"; "LKML";

Re: [PATCH] genirq/affinity: Assign default affinity to pre/post vectors

陈华才 江苏中科梦兰电子科技有限公司/自主安全事业部/软件部 江苏常熟虞山镇梦兰村 -- Original -- From: "Thomas Gleixner"; Date: Wed, Jan 16, 2019 05:26 PM To: "陈华才"; Cc: "linux-kernel"; "Fuxin Zhang"; "wuzhangjin"; "stable"; &qu

Re: [PATCH] genirq/affinity: Assign default affinity to pre/post vectors

Hi, Thomas, I'm not removing all return NULL of irq_create_affinity_masks(), so the memory allocation failure still return NULL. I just handle the case that there are not enough irq vectors. E.g. in nvme driver, the caller may call irq_create_affinity_masks() with

Re: [[PATCH]] mips: Fix switch to NO_BOOTMEM for SGI-IP27/loongons3 NUMA

Hi, It seems the patch below can solve many problems after switched to NO_BOOTMEM, because the memory allocation behavior is more similar as before. diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 070234b..7a449d9 100644 --- a/arch/mips/kernel/setup.c +++

Re: [[PATCH]] mips: Fix switch to NO_BOOTMEM for SGI-IP27/loongons3 NUMA

Hi, It seems the patch below can solve many problems after switched to NO_BOOTMEM, because the memory allocation behavior is more similar as before. diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c index 070234b..7a449d9 100644 --- a/arch/mips/kernel/setup.c +++

Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails

Hi, Sudeep, I use MIPS, and there is no "size" in /sys/devices/system/cpu/cpuX/cache/indexX/ file after your patch. Because the DT node only has "next-level-cache = <>;" but has no "size" information. Huacai -- Original -- From: "Sudeep Holla"; Date: Thu,

Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails

Hi, Sudeep, I use MIPS, and there is no "size" in /sys/devices/system/cpu/cpuX/cache/indexX/ file after your patch. Because the DT node only has "next-level-cache = <>;" but has no "size" information. Huacai -- Original -- From: "Sudeep Holla"; Date: Thu,

Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

Hi, Paul, SFB can improve the memory bandwidth as much as 30%, and we are planning to enable SFB by default. So, we want to control cpu_relax() under CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT. Huacai -- Original -- From: "Paul Burton";

Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3

Hi, Paul, SFB can improve the memory bandwidth as much as 30%, and we are planning to enable SFB by default. So, we want to control cpu_relax() under CONFIG_CPU_LOONGSON3, not under CONFIG_LOONGSON3_ENHANCEMENT. Huacai -- Original -- From: "Paul Burton";

Re: [PATCH 4.9 03/32] MIPS: Use asyncIPIsforarch_trigger_cpumask_backtrace()

19 Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Tue, Jul 17, 2018 03:20 PM To: "陈华才"; Cc: "linux-kernel"; "stable"; "Paul Burton"; "James Hogan"; Subject: Re: [PATCH 4.9 03/32] MIPS: Use asy

Re: [PATCH 4.9 03/32] MIPS: Use asyncIPIsforarch_trigger_cpumask_backtrace()

19 Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Tue, Jul 17, 2018 03:20 PM To: "陈华才"; Cc: "linux-kernel"; "stable"; "Paul Burton"; "James Hogan"; Subject: Re: [PATCH 4.9 03/32] MIPS: Use asy

Re: [PATCH 4.9 03/32] MIPS: Use async IPIsforarch_trigger_cpumask_backtrace()

Hi, Greg, I have backported and tested it to 4.9 and 4.4: https://patchwork.linux-mips.org/patch/19862/ https://patchwork.linux-mips.org/patch/19863/ Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Tue, Jul 17, 2018 02:34 AM To: "陈华

Re: [PATCH 4.9 03/32] MIPS: Use async IPIsforarch_trigger_cpumask_backtrace()

Hi, Greg, I have backported and tested it to 4.9 and 4.4: https://patchwork.linux-mips.org/patch/19862/ https://patchwork.linux-mips.org/patch/19863/ Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Tue, Jul 17, 2018 02:34 AM To: "陈华

Re: [PATCH 4.9 03/32] MIPS: Use async IPIs forarch_trigger_cpumask_backtrace()

Just change "call_single_data_t" to "struct call_single_data" and everything is OK. Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Mon, Jul 16, 2018 05:40 PM To: "陈华才"; Cc: "linux-kernel"; &quo

Re: [PATCH 4.9 03/32] MIPS: Use async IPIs forarch_trigger_cpumask_backtrace()

Just change "call_single_data_t" to "struct call_single_data" and everything is OK. Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Mon, Jul 16, 2018 05:40 PM To: "陈华才"; Cc: "linux-kernel"; &quo

Re:[PATCH 4.9 03/32] MIPS: Use async IPIs for arch_trigger_cpumask_backtrace()

Hi, Greg, kernel-4.9 doesn't have call_single_data_t, we should use struct call_single_data instead. Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Mon, Jul 16, 2018 03:36 PM To: "linux-kernel"; Cc: "Greg Kroah-Hartman"; "stable"; "Paul Burton";

Re:[PATCH 4.9 03/32] MIPS: Use async IPIs for arch_trigger_cpumask_backtrace()

Hi, Greg, kernel-4.9 doesn't have call_single_data_t, we should use struct call_single_data instead. Huacai -- Original -- From: "Greg Kroah-Hartman"; Date: Mon, Jul 16, 2018 03:36 PM To: "linux-kernel"; Cc: "Greg Kroah-Hartman"; "stable"; "Paul Burton";

Re: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3

Hi, Peter, I'm afraid that you have missing something.. Firstly, our previous conclusion (READ_ONCE need a barrier to avoid 'reads prioritised over writes') is totally wrong. So define cpu_relax() to smp_mb() like ARM11MPCore is incorrect, even if it can 'solve' Loongson's problem.

Re: [PATCH V2] MIPS: implement smp_cond_load_acquire() for Loongson-3

Hi, Peter, I'm afraid that you have missing something.. Firstly, our previous conclusion (READ_ONCE need a barrier to avoid 'reads prioritised over writes') is totally wrong. So define cpu_relax() to smp_mb() like ARM11MPCore is incorrect, even if it can 'solve' Loongson's problem.

Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

ads prioritised over writes", which is caused by SFB's weak ordering and similar to ARM11MPCore (mentioned by Will Deacon). Huacai -- Original -- From: "Peter Zijlstra"; Date: Tue, Jun 19, 2018 03:22 PM To: "陈华才"; Cc: "Paul Burton&

Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

ads prioritised over writes", which is caused by SFB's weak ordering and similar to ARM11MPCore (mentioned by Will Deacon). Huacai -- Original -- From: "Peter Zijlstra"; Date: Tue, Jun 19, 2018 03:22 PM To: "陈华才"; Cc: "Paul Burton&

Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

Hi, Paul, First of all, could you please check why linux-mips reject e-mails from lemote.com? Of course I can send e-mails by gmail, but my gmail can't receive e-mails from linux-mips since March, 2018. I have already read Documentation/memory-barriers.txt, but I don't think we should define

Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

Hi, Paul, First of all, could you please check why linux-mips reject e-mails from lemote.com? Of course I can send e-mails by gmail, but my gmail can't receive e-mails from linux-mips since March, 2018. I have already read Documentation/memory-barriers.txt, but I don't think we should define

Re: Regression with arm in next with stack protector

Allwinner devices are OK, Exynos devices (except 4210) are OK. -- Original -- From: "Tony Lindgren"<t...@atomide.com>; Date: Mon, Mar 26, 2018 11:37 PM To: "陈华才"<che...@lemote.com>; Cc: "Andrew Morton"<a...@

Re: Regression with arm in next with stack protector

Allwinner devices are OK, Exynos devices (except 4210) are OK. -- Original -- From: "Tony Lindgren"; Date: Mon, Mar 26, 2018 11:37 PM To: "陈华才"; Cc: "Andrew Morton"; "Fabio Estevam"; "Stephen Rothwell"

Re: Regression with arm in next with stack protector

Hi, Tony and Fabio, Could you please upload your kernel binary to somewhere for me? I don't understand why some ARM boards is OK while others are broken. Huacai -- Original -- From: "Andrew Morton"; Date: Sat, Mar 24, 2018 03:15 AM

Re: Regression with arm in next with stack protector

Hi, Tony and Fabio, Could you please upload your kernel binary to somewhere for me? I don't understand why some ARM boards is OK while others are broken. Huacai -- Original -- From: "Andrew Morton"; Date: Sat, Mar 24, 2018 03:15 AM To: "Fabio Estevam"; Cc:

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

But in b44_init(), there is no device instances. -- Original -- From: "Christoph Hellwig"; Date: Fri, Nov 10, 2017 08:30 PM To: "Huacai Chen"; Cc: "Christoph Hellwig"; "Marek

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

But in b44_init(), there is no device instances. -- Original -- From: "Christoph Hellwig"; Date: Fri, Nov 10, 2017 08:30 PM To: "Huacai Chen"; Cc: "Christoph Hellwig"; "Marek Szyprowski"; "Robin Murphy"; "Andrew Morton"; "Fuxin Zhang"; "linux-kernel";

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Only patch 4 can be merged to stable, please ignore cc-stable in the rest. -- Original -- From: "Christoph Hellwig"<h...@lst.de>; Date: Fri, Nov 3, 2017 01:14 PM To: "陈华才"<che...@lemote.com>; Cc: "Marek Szyprowski&q

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Only patch 4 can be merged to stable, please ignore cc-stable in the rest. -- Original -- From: "Christoph Hellwig"; Date: Fri, Nov 3, 2017 01:14 PM To: "陈华才"; Cc: "Marek Szyprowski"; "Christoph Hellwig"; "

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Why this is still un-merged? Should I remove the cc-stable and resend this series? Huacai -- Original -- From: "陈华才"<che...@lemote.com>; Date: Thu, Oct 26, 2017 02:33 PM To: "Marek Szyprowski"<m.szyprow...@samsung.com>;

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Why this is still un-merged? Should I remove the cc-stable and resend this series? Huacai -- Original -- From: "陈华才"; Date: Thu, Oct 26, 2017 02:33 PM To: "Marek Szyprowski"; "Christoph Hellwig"; Cc: "Robin Murp

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Maybe my first version is suitable for stable. Huacai -- Original -- From: "Marek Szyprowski"<m.szyprow...@samsung.com>; Date: Wed, Oct 25, 2017 03:21 PM To: "陈华才"<che...@lemote.com>; "Christoph Hellwig"<

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Maybe my first version is suitable for stable. Huacai -- Original -- From: "Marek Szyprowski"; Date: Wed, Oct 25, 2017 03:21 PM To: "陈华才"; "Christoph Hellwig"; Cc: "Robin Murphy"; "Andrew Morton&quo

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Hi, Marek Patch3 is needed for stable, but Patch3 depend on Patch1 and Patch2. Huacai -- Original -- From: "Marek Szyprowski"; Date: Tue, Oct 24, 2017 09:30 PM To: "Huacai Chen"; "Christoph Hellwig";

Re: [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

Hi, Marek Patch3 is needed for stable, but Patch3 depend on Patch1 and Patch2. Huacai -- Original -- From: "Marek Szyprowski"; Date: Tue, Oct 24, 2017 09:30 PM To: "Huacai Chen"; "Christoph Hellwig"; Cc: "Robin Murphy"; "Andrew Morton"; "Fuxin Zhang";

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Matt, I found that 4ee34ea3a12396f35b26d90a094c75db ("libata: Align ata_device's id on a cacheline") can resolve everything. Because the size of id[ATA_ID_WORDS] is already aligned and devslp_timing needn't to be aligned. So, In V9 of this series I will drop this patch. Why I had problems

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Matt, I found that 4ee34ea3a12396f35b26d90a094c75db ("libata: Align ata_device's id on a cacheline") can resolve everything. Because the size of id[ATA_ID_WORDS] is already aligned and devslp_timing needn't to be aligned. So, In V9 of this series I will drop this patch. Why I had problems

Re: [PATCH V8 4/5] libsas: Align SMP req/resp todma_get_cache_alignment()

Hi, Marek, Yes, I know in include/linux/slab.h, there is #define KMALLOC_MIN_SIZE ARCH_DMA_MINALIGN But I observed that the req/resp isn't aligned to ARCH_DMA_MINALIGN and I don't know why. Problems I experienced is: In non-coherent mode, mvsas with an expander cannot detect any disks.

Re: [PATCH V8 4/5] libsas: Align SMP req/resp todma_get_cache_alignment()

Hi, Marek, Yes, I know in include/linux/slab.h, there is #define KMALLOC_MIN_SIZE ARCH_DMA_MINALIGN But I observed that the req/resp isn't aligned to ARCH_DMA_MINALIGN and I don't know why. Problems I experienced is: In non-coherent mode, mvsas with an expander cannot detect any disks.

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Sergei, Without this patch, in non-coherent mode, ata_do_set_mode() return with "no PIO support", and disk detection fails. Huacai -- Original -- From: "Sergei Shtylyov"; Date: Tue, Oct 17, 2017 05:43 PM To: "Huacai

Re: [PATCH V8 5/5] libata: Align DMA buffer todma_get_cache_alignment()

Hi, Sergei, Without this patch, in non-coherent mode, ata_do_set_mode() return with "no PIO support", and disk detection fails. Huacai -- Original -- From: "Sergei Shtylyov"; Date: Tue, Oct 17, 2017 05:43 PM To: "Huacai Chen"; "Christoph Hellwig"; Cc:

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Christoph, Can I put the declaration in asm/dma-coherence.h? And, last time you said it is OK to pass a NULL to dma_get_cache_alignment() and cc all driver maintainers. I have do so. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon,

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Christoph, Can I put the declaration in asm/dma-coherence.h? And, last time you said it is OK to pass a NULL to dma_get_cache_alignment() and cc all driver maintainers. I have do so. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 25, 2017

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Robin, Can ARM/ARM64 use the same implementation as MIPS? Or I just do MIPS things is OK? Huacai -- Original -- From: "Robin Murphy"; Date: Mon, Sep 25, 2017 08:57 PM To: "Huacai Chen"; "Christoph

Re: [PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

Hi, Robin, Can ARM/ARM64 use the same implementation as MIPS? Or I just do MIPS things is OK? Huacai -- Original -- From: "Robin Murphy"; Date: Mon, Sep 25, 2017 08:57 PM To: "Huacai Chen"; "Christoph Hellwig"; Cc: "Marek Szyprowski"; "Andrew Morton";

Re: [PATCH V6 1/3] dma-mapping: Introduce device_is_coherent() as ahelper

Hi, Robin, Before 2.6.36 dma_get_cache_alignment is arch-dependent, and it is unified in commit 4565f0170dfc849b3629c27d7 ("dma-mapping: unify dma_get_cache_alignment implementations"). Should we revert to the old implementation? Huacai -- Original -- From:

Re: [PATCH V6 1/3] dma-mapping: Introduce device_is_coherent() as ahelper

Hi, Robin, Before 2.6.36 dma_get_cache_alignment is arch-dependent, and it is unified in commit 4565f0170dfc849b3629c27d7 ("dma-mapping: unify dma_get_cache_alignment implementations"). Should we revert to the old implementation? Huacai -- Original -- From:

Re: [PATCH V6 2/3] dma-mapping: Rework dma_get_cache_alignment()function

Hi, Christoph, I have changed dma_get_cache_alignment's return value, and I don't know whether those drivers want to return ARCH_DMA_MINALIGN unconditionally. So I pass a NULL for those drivers, in order to keep their old behavior. Huacai -- Original -- From:

Re: [PATCH V6 2/3] dma-mapping: Rework dma_get_cache_alignment()function

Hi, Christoph, I have changed dma_get_cache_alignment's return value, and I don't know whether those drivers want to return ARCH_DMA_MINALIGN unconditionally. So I pass a NULL for those drivers, in order to keep their old behavior. Huacai -- Original -- From:

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Oh, I know, I've make a mistake, dmapool doesn't need to change. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 18, 2017 11:51 PM To: "Robin Murphy"; Cc: "Huacai Chen"; "Andrew

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Oh, I know, I've make a mistake, dmapool doesn't need to change. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 18, 2017 11:51 PM To: "Robin Murphy"; Cc: "Huacai Chen"; "Andrew Morton"; "Fuxin Zhang"; "linux-mm"; "linux-kernel";

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph, I don't think dma_get_cache_alignment is the "absolute minimum alignment" in all cases. At least on MIPS/Loongson, if we use I/O coherent mode (Cached DMA mode), align block queue to 4Bytes is enough. If we align block queue to dma_get_cache_alignment in I/O coherent mode,

Re: [PATCH V5 3/3] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph, I don't think dma_get_cache_alignment is the "absolute minimum alignment" in all cases. At least on MIPS/Loongson, if we use I/O coherent mode (Cached DMA mode), align block queue to 4Bytes is enough. If we align block queue to dma_get_cache_alignment in I/O coherent mode,

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph, Maybe you missed something. 1, pool_alloc_page() use dma_alloc_coherent() to allocate pool pages, and of course these pages are aligned to ARCH_DMA_MINALIGN. 2, dma_pool_alloc() is the element allocator, but it doesn't use dma_alloc_coherent(). Elements only align to pool->size,

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph, Maybe you missed something. 1, pool_alloc_page() use dma_alloc_coherent() to allocate pool pages, and of course these pages are aligned to ARCH_DMA_MINALIGN. 2, dma_pool_alloc() is the element allocator, but it doesn't use dma_alloc_coherent(). Elements only align to pool->size,

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Andrew, It will cause data corruption, at least on MIPS: step 1, dma_map_single step 2, cache_invalidate (no writeback) step 3, dma_from_device step 4, dma_unmap_single If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data,

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Andrew, It will cause data corruption, at least on MIPS: step 1, dma_map_single step 2, cache_invalidate (no writeback) step 3, dma_from_device step 4, dma_unmap_single If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data,

Re: [PATCH 2/2] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph I think we cannot modify dma_get_cache_alignment(), because existing callers may want to unconditionally return ARCH_DMA_MINALIGN. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 11, 2017 03:39 PM To:

Re: [PATCH 2/2] scsi: Align queue to ARCH_DMA_MINALIGN innon-coherent DMA mode

Hi, Christoph I think we cannot modify dma_get_cache_alignment(), because existing callers may want to unconditionally return ARCH_DMA_MINALIGN. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 11, 2017 03:39 PM To: "Huacai Chen"; Cc:

Re:mips builds failing in v3.18.38 and v4.1.29

Hi, I have already told Sasha that "MIPS: Reserve nosave data for hibernation" should not be backported to 4.1/3.18. But he has no response. Huacai -- Original -- From: "Guenter Roeck"; Date: Mon, Aug 1, 2016 07:57 AM To: "Sasha

Re:mips builds failing in v3.18.38 and v4.1.29

Hi, I have already told Sasha that "MIPS: Reserve nosave data for hibernation" should not be backported to 4.1/3.18. But he has no response. Huacai -- Original -- From: "Guenter Roeck"; Date: Mon, Aug 1, 2016 07:57 AM To: "Sasha Levin"; Cc: "stable";

Re:next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

Hi, Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks. Huacai -- Original -- From: "Guenter Roeck"; Date: Wed, Apr 20, 2016

Re:next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'

Hi, Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks. Huacai -- Original -- From: "Guenter Roeck"; Date: Wed, Apr 20, 2016 10:54 AM To:

Re:[PATCH] mips: Fix console output for Fulong2e system

Acked-by: Huacai Chen -- Original -- From: "Guenter Roeck"; Date: Fri, Aug 7, 2015 01:57 PM To: "Ralf Baechle"; Cc: "Huacai Chen"; "linux-mips"; "linux-kernel"; "Guenter Roeck"; Subject: [PATCH] mips: Fix console output for Fulong2e system Commit

Re:[PATCH] mips: Fix console output for Fulong2e system

Acked-by: Huacai Chen che...@lemote.com -- Original -- From: Guenter Roeckli...@roeck-us.net; Date: Fri, Aug 7, 2015 01:57 PM To: Ralf Baechler...@linux-mips.org; Cc: Huacai Chenche...@lemote.com; linux-mipslinux-m...@linux-mips.org;

Re:[PATCH -next] MIPS: Remove duplicated include from numa.c

Reviewed-off-by: Huacai Chen -- Original -- From: "weiyj_lk"; Date: Tue, Aug 12, 2014 08:26 PM To: "Ralf Baechle"; "Huacai Chen"; Cc: "Wei Yongjun"; "linux-mips"; "linux-kernel"; Subject: [PATCH -next] MIPS: Remove duplicated include from numa.c From:

Re:[PATCH -next] MIPS: Remove duplicated include from numa.c

Reviewed-off-by: Huacai Chen che...@lemote.com -- Original -- From: weiyj_lkweiyj...@163.com; Date: Tue, Aug 12, 2014 08:26 PM To: Ralf Baechler...@linux-mips.org; Huacai Chenche...@lemote.com; Cc: Wei Yongjunyongjun_...@trendmicro.com.cn;

Re: [PATCH] genirq: Avoid NULL OOPS in irq handling

> On Wed, 30 Oct 2013, "陈华才" wrote: > >> I use a Loongson-3(MIPS-series CPU) machine, there is a serial port >> integrated in the CPU (but it iss buggy), and it use handle_percpu_irq() >> as the irq handler. Maybe I should move the checking into >>

Re: [PATCH] genirq: Avoid NULL OOPS in irq handling

I use a Loongson-3(MIPS-series CPU) machine, there is a serial port integrated in the CPU (but it iss buggy), and it use handle_percpu_irq() as the irq handler. Maybe I should move the checking into handle_percpu_irq()? Huacai > On Sat, 28 Sep 2013, Huacai Chen wrote: > >> Some devices (e.g.

Re: [PATCH] genirq: Avoid NULL OOPS in irq handling

I use a Loongson-3(MIPS-series CPU) machine, there is a serial port integrated in the CPU (but it iss buggy), and it use handle_percpu_irq() as the irq handler. Maybe I should move the checking into handle_percpu_irq()? Huacai On Sat, 28 Sep 2013, Huacai Chen wrote: Some devices (e.g. serial

Re: [PATCH] genirq: Avoid NULL OOPS in irq handling

On Wed, 30 Oct 2013, 陈华才 wrote: I use a Loongson-3(MIPS-series CPU) machine, there is a serial port integrated in the CPU (but it iss buggy), and it use handle_percpu_irq() as the irq handler. Maybe I should move the checking into handle_percpu_irq()? Why is a device interrupt using

Re: [PATCH V2 01/14] MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem

build_r4000_tlb_modify_handler(); > + if (!cpu_has_local_ebase) > + build_r4000_tlb_refill_handler(); > run_once++; > } > - build_r4000_tlb_refill_handler(); > + if (c

Re: [PATCH V2 01/14] MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem

-- 江苏中科梦兰电子科技有限公司 软件部 陈华才 E-mail: che...@lemote.com Web: http://www.lemote.com/ Add: 江苏省常熟市虞山镇梦兰工业园 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

John, for patch 3 reworking, please tell me whether my understanding is correct? (make cpu_has_coherent_cache as a runtime option rather than config option), thank you very much. > Hi, > > ok, i dropped the series for now from my tree > > John > -- To unsubscribe from this list: send

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

John, for patch 3 reworking, please tell me whether my understanding is correct? (make cpu_has_coherent_cache as a runtime option rather than config option), thank you very much. Hi, ok, i dropped the series for now from my tree John -- To unsubscribe from this list: send the

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

#ifndef cpu_has_coherent_cache #define cpu_has_coherent_cache (cpu_data[0].options & MIPS_CPU_INCLUSIVE_CACHES) #endif Besides, the SMP code has a bug to fix (IPI sending) and patch 3, patch 6 need to update. So I think a V9 is needed :( > On 25/01/13 01:15, 陈华才 wrote: >> ok, I'

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

#ifndef cpu_has_coherent_cache #define cpu_has_coherent_cache (cpu_data[0].options MIPS_CPU_INCLUSIVE_CACHES) #endif Besides, the SMP code has a bug to fix (IPI sending) and patch 3, patch 6 need to update. So I think a V9 is needed :( On 25/01/13 01:15, 陈华才 wrote: ok, I'll prepare v9

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

> http://patchwork.linux-mips.org/patch/4547/ has a few comments. Please > prepare a patch asap to address those so i can fold it into the series. > > John > -- 江苏中科梦兰电子科技有限公司 软件部 陈华才 E-mail: che...@lemote.com Web: http://www.lemote.com/ Add: 江苏省常熟市虞山镇梦兰工业园 -- To unsub

Re: [PATCH V8 00/13] MIPS: Add Loongson-3 based machines support

-john.git;a=shortlog;h=refs/heads/mips-next-3.9 I cleaned up a few minor whitespace errors while merging. http://patchwork.linux-mips.org/patch/4547/ has a few comments. Please prepare a patch asap to address those so i can fold it into the series. John -- 江苏中科梦兰电子科技有限公司 软件部 陈华才 E

Re: [RFC][PATCH] sched: Fix a deadlock of cpu-hotplug

> On Wed, 2012-10-24 at 20:34 +0800, 陈华才 wrote: >> I see, this is an arch-specific bug, sorry for my carelessness and thank >> you for your tips. > > What arch are you using? And what exactly did the arch do wrong? Most of > the code involved seems to b

Re: [RFC][PATCH] sched: Fix a deadlock of cpu-hotplug

> On Wed, 2012-10-24 at 17:25 +0800, Huacai Chen wrote: >> We found poweroff sometimes fails on our computers, so we have the >> lock debug options configured. Then, when we do poweroff or take a >> cpu down via cpu-hotplug, kernel complain as below. To resove this, >> we modify

Re: [RFC][PATCH] sched: Fix a deadlock of cpu-hotplug

On Wed, 2012-10-24 at 17:25 +0800, Huacai Chen wrote: We found poweroff sometimes fails on our computers, so we have the lock debug options configured. Then, when we do poweroff or take a cpu down via cpu-hotplug, kernel complain as below. To resove this, we modify sched_ttwu_pending(),

Re: [RFC][PATCH] sched: Fix a deadlock of cpu-hotplug

On Wed, 2012-10-24 at 20:34 +0800, 陈华才 wrote: I see, this is an arch-specific bug, sorry for my carelessness and thank you for your tips. What arch are you using? And what exactly did the arch do wrong? Most of the code involved seems to be common code. Going by c0_compare_interrupt

Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch

So I still think that "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch... > On 10/06/2012 01:23 AM, Peter Zijlstra wrote: >> On Fri, 2012-10-05 at 10:10 -0700, Jonathan Nieder wrote: >>> Peter Zijlstra wrote: On Thu, 2012-10-04 at 15:27 -0700, Greg

Re: Seems like sched: Add missing call to calc_load_exit_idle() should be reverted in 3.5 branch

So I still think that sched: Add missing call to calc_load_exit_idle() should be reverted in 3.5 branch... On 10/06/2012 01:23 AM, Peter Zijlstra wrote: On Fri, 2012-10-05 at 10:10 -0700, Jonathan Nieder wrote: Peter Zijlstra wrote: On Thu, 2012-10-04 at 15:27 -0700, Greg Kroah-Hartman wrote:

Re: Seems like "sched: Add missing call to calc_load_exit_idle()" should be reverted in 3.5 branch

pling load muck >> and calling calc_load_exit_idle() from there is bound to confuse state. >> >> I hope.. damn this code ;-) >> >> I can't find wtf went wrong either, the initial patch 5167e8d5417bf5c >> contains both hunks, but in that case the fixup 749c8814

Re: Seems like sched: Add missing call to calc_load_exit_idle() should be reverted in 3.5 branch

, but in that case the fixup 749c8814f0 doesn't make sense, not can I find anything in merge commits using: git log -S calc_load_exit_idle kernel/time/tick-sched.c /me puzzled I'm puzzled as well. Any ideas if I should do anything here or not? greg k-h -- 江苏中科梦兰电子科技有限公司 软件部 陈华才 E